S
server
Guest
message unavailable
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
P
PROYMAV
Guest
It seems that OrCAD capture does not like to save project through a long path, try with a short one, I solved this problem in this way, no more errors DMS0006!
V
Vincent Li
Guest
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
ripI\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
V
Vincent Li
Guest
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
ripI\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
V
Vincent Li
Guest
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
ripI\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
V
Vincent Li
Guest
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
2nd thisI\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
V
Vincent Li
Guest
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
ripI\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
M
Mike Perkins
Guest
On 09/11/2021 14:14, Vincent Li wrote:
Do you really mean checksum, or CRC?
Checksum is easy to understand, CRC less so.
I confess it\'s a long time since I used/looked up first principles to
generate CRCs and use this website:
https://www.easics.com/crctool/
--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
I\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
rip
Do you really mean checksum, or CRC?
Checksum is easy to understand, CRC less so.
I confess it\'s a long time since I used/looked up first principles to
generate CRCs and use this website:
https://www.easics.com/crctool/
--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk
M
Mike Perkins
Guest
On 09/11/2021 14:14, Vincent Li wrote:
Do you really mean checksum, or CRC?
Checksum is easy to understand, CRC less so.
I confess it\'s a long time since I used/looked up first principles to
generate CRCs and use this website:
https://www.easics.com/crctool/
--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
I\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
rip
Do you really mean checksum, or CRC?
Checksum is easy to understand, CRC less so.
I confess it\'s a long time since I used/looked up first principles to
generate CRCs and use this website:
https://www.easics.com/crctool/
--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk
G
gnuarm.del...@gmail.com
Guest
On Wednesday, November 10, 2021 at 12:39:22 PM UTC-4, Mike Perkins wrote:
The only hard part to CRC is understanding the nomenclature. There are several options for computing CRCs based on polarity and direction. Specifying this is not consistent and often it is assumed that you know the \"standard\". With the combinations it can be very hard to get it right and be able to verify that. So by all means make sure you verify your results in the simplest medium you can before proceeding to anything more complex like coding.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
On 09/11/2021 14:14, Vincent Li wrote:
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
I\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
rip
Do you really mean checksum, or CRC?
Checksum is easy to understand, CRC less so.
I confess it\'s a long time since I used/looked up first principles to
generate CRCs and use this website:
https://www.easics.com/crctool/
The only hard part to CRC is understanding the nomenclature. There are several options for computing CRCs based on polarity and direction. Specifying this is not consistent and often it is assumed that you know the \"standard\". With the combinations it can be very hard to get it right and be able to verify that. So by all means make sure you verify your results in the simplest medium you can before proceeding to anything more complex like coding.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
D
David Brown
Guest
On 20/11/2021 15:19, gnuarm.del...@gmail.com wrote:
That\'s what I usually see as a challenge for CRC\'s - getting different
implementations to agree. If you can use the same implementation on all
parts, then the details (bit ordering, polarity, polynomial, etc.) don\'t
matter. My usual solution is using a lookup table of 256 entries. It\'s
simple for 8-bit CRC\'s, and not too difficult for 16-bit or 32-bit
CRC\'s, and should be as straightforward to make on an FPGA as it is in
C, Python, or whatever programming language takes your fancy. That
makes it easy to get matching results on multiple systems. But it would
take a bit more FPGA resources than a bit-wise linear feedback register.
On Wednesday, November 10, 2021 at 12:39:22 PM UTC-4, Mike Perkins
wrote:
On 09/11/2021 14:14, Vincent Li wrote:
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
I\'m looking for checksum implementation in VHDL (or at least
the basic rules to build one). Regards Ron
rip
Do you really mean checksum, or CRC?
Checksum is easy to understand, CRC less so.
I confess it\'s a long time since I used/looked up first principles
to generate CRCs and use this website:
https://www.easics.com/crctool/
The only hard part to CRC is understanding the nomenclature. There
are several options for computing CRCs based on polarity and
direction. Specifying this is not consistent and often it is assumed
that you know the \"standard\". With the combinations it can be very
hard to get it right and be able to verify that. So by all means
make sure you verify your results in the simplest medium you can
before proceeding to anything more complex like coding.
That\'s what I usually see as a challenge for CRC\'s - getting different
implementations to agree. If you can use the same implementation on all
parts, then the details (bit ordering, polarity, polynomial, etc.) don\'t
matter. My usual solution is using a lookup table of 256 entries. It\'s
simple for 8-bit CRC\'s, and not too difficult for 16-bit or 32-bit
CRC\'s, and should be as straightforward to make on an FPGA as it is in
C, Python, or whatever programming language takes your fancy. That
makes it easy to get matching results on multiple systems. But it would
take a bit more FPGA resources than a bit-wise linear feedback register.
V
Vincent Li
Guest
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
2nd thisI\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
V
Vincent Li
Guest
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
2nd thisI\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
G
gnuarm.del...@gmail.com
Guest
On Wednesday, November 10, 2021 at 12:39:22 PM UTC-4, Mike Perkins wrote:
The only hard part to CRC is understanding the nomenclature. There are several options for computing CRCs based on polarity and direction. Specifying this is not consistent and often it is assumed that you know the \"standard\". With the combinations it can be very hard to get it right and be able to verify that. So by all means make sure you verify your results in the simplest medium you can before proceeding to anything more complex like coding.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
On 09/11/2021 14:14, Vincent Li wrote:
onsdag den 5. april 2000 kl. 09.00.00 UTC+2 skrev Ron:
I\'m looking for checksum implementation in VHDL (or at least the basic rules
to build one).
Regards
Ron
rip
Do you really mean checksum, or CRC?
Checksum is easy to understand, CRC less so.
I confess it\'s a long time since I used/looked up first principles to
generate CRCs and use this website:
https://www.easics.com/crctool/
The only hard part to CRC is understanding the nomenclature. There are several options for computing CRCs based on polarity and direction. Specifying this is not consistent and often it is assumed that you know the \"standard\". With the combinations it can be very hard to get it right and be able to verify that. So by all means make sure you verify your results in the simplest medium you can before proceeding to anything more complex like coding.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
L
Luis Benites
Guest
On Monday, October 27, 2014 at 11:05:32 AM UTC-7, david....@gmail.com wrote:
Just in case this is what you are trying to so: stalling your whole system and all other PCIe accesses to wait for an i2c read should never be the solution to anything. You send your completion whenever it\'s ready. If it takes you longer than the spec to complete then you need to initiate the read in some other way (earlier), check for ready and only then issue the read you can complete on time.
What is the correct way to handle a PCIE request to a slow device?
I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
The BAR memory map is decoded and some addresses map to fast ram, or local registers and these work OK,
but some addresses map to slow devices.. like I2C or internal processes that need a few cycles to process before they can produce valid data to be returned to the PCI bus.
Is there a way to tell the PCI bus to wait, or retry..?
thanks
Just in case this is what you are trying to so: stalling your whole system and all other PCIe accesses to wait for an i2c read should never be the solution to anything. You send your completion whenever it\'s ready. If it takes you longer than the spec to complete then you need to initiate the read in some other way (earlier), check for ready and only then issue the read you can complete on time.
L
Luis Benites
Guest
On Monday, October 27, 2014 at 11:05:32 AM UTC-7, david....@gmail.com wrote:
Just in case this is what you are trying to so: stalling your whole system and all other PCIe accesses to wait for an i2c read should never be the solution to anything. You send your completion whenever it\'s ready. If it takes you longer than the spec to complete then you need to initiate the read in some other way (earlier), check for ready and only then issue the read you can complete on time.
What is the correct way to handle a PCIE request to a slow device?
I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
The BAR memory map is decoded and some addresses map to fast ram, or local registers and these work OK,
but some addresses map to slow devices.. like I2C or internal processes that need a few cycles to process before they can produce valid data to be returned to the PCI bus.
Is there a way to tell the PCI bus to wait, or retry..?
thanks
Just in case this is what you are trying to so: stalling your whole system and all other PCIe accesses to wait for an i2c read should never be the solution to anything. You send your completion whenever it\'s ready. If it takes you longer than the spec to complete then you need to initiate the read in some other way (earlier), check for ready and only then issue the read you can complete on time.
D
David Brown
Guest
On 09/03/2021 03:52, Luis Benites wrote:
Please look at the date of the post you are replying to. Do you think
someone will have been waiting over six years for an answer to a Usenet
post? It\'s nice that you are trying to help, of course.
On Monday, October 27, 2014 at 11:05:32 AM UTC-7, david....@gmail.com
wrote:
What is the correct way to handle a PCIE request to a slow device?
I have a xilinx spartan 6 PCIe using Integrated Block for PCI
Express.
The BAR memory map is decoded and some addresses map to fast ram,
or local registers and these work OK, but some addresses map to
slow devices.. like I2C or internal processes that need a few
cycles to process before they can produce valid data to be returned
to the PCI bus.
Is there a way to tell the PCI bus to wait, or retry..?
thanks
Just in case this is what you are trying to so: stalling your whole
system and all other PCIe accesses to wait for an i2c read should
never be the solution to anything. You send your completion whenever
it\'s ready. If it takes you longer than the spec to complete then you
need to initiate the read in some other way (earlier), check for
ready and only then issue the read you can complete on time.
Please look at the date of the post you are replying to. Do you think
someone will have been waiting over six years for an answer to a Usenet
post? It\'s nice that you are trying to help, of course.
D
David Brown
Guest
On 09/03/2021 03:52, Luis Benites wrote:
Please look at the date of the post you are replying to. Do you think
someone will have been waiting over six years for an answer to a Usenet
post? It\'s nice that you are trying to help, of course.
On Monday, October 27, 2014 at 11:05:32 AM UTC-7, david....@gmail.com
wrote:
What is the correct way to handle a PCIE request to a slow device?
I have a xilinx spartan 6 PCIe using Integrated Block for PCI
Express.
The BAR memory map is decoded and some addresses map to fast ram,
or local registers and these work OK, but some addresses map to
slow devices.. like I2C or internal processes that need a few
cycles to process before they can produce valid data to be returned
to the PCI bus.
Is there a way to tell the PCI bus to wait, or retry..?
thanks
Just in case this is what you are trying to so: stalling your whole
system and all other PCIe accesses to wait for an i2c read should
never be the solution to anything. You send your completion whenever
it\'s ready. If it takes you longer than the spec to complete then you
need to initiate the read in some other way (earlier), check for
ready and only then issue the read you can complete on time.
Please look at the date of the post you are replying to. Do you think
someone will have been waiting over six years for an answer to a Usenet
post? It\'s nice that you are trying to help, of course.
L
Luis Benites
Guest
On Tuesday, March 9, 2021 at 10:56:20 AM UTC-8, David Brown wrote:
Ha ha. Let\'s start a flame war over trying to help. Don\'t you have better use of your time? Anyone looking for CURRECT PCIe help with a google search will come across this post and get something from it. Nothing that was said is outdated.
On 09/03/2021 03:52, Luis Benites wrote:
On Monday, October 27, 2014 at 11:05:32 AM UTC-7, david....@gmail.com
wrote:
What is the correct way to handle a PCIE request to a slow device?
I have a xilinx spartan 6 PCIe using Integrated Block for PCI
Express.
The BAR memory map is decoded and some addresses map to fast ram,
or local registers and these work OK, but some addresses map to
slow devices.. like I2C or internal processes that need a few
cycles to process before they can produce valid data to be returned
to the PCI bus.
Is there a way to tell the PCI bus to wait, or retry..?
thanks
Just in case this is what you are trying to so: stalling your whole
system and all other PCIe accesses to wait for an i2c read should
never be the solution to anything. You send your completion whenever
it\'s ready. If it takes you longer than the spec to complete then you
need to initiate the read in some other way (earlier), check for
ready and only then issue the read you can complete on time.
Please look at the date of the post you are replying to. Do you think
someone will have been waiting over six years for an answer to a Usenet
post? It\'s nice that you are trying to help, of course.
Ha ha. Let\'s start a flame war over trying to help. Don\'t you have better use of your time? Anyone looking for CURRECT PCIe help with a google search will come across this post and get something from it. Nothing that was said is outdated.