Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 2/18/18 3:42 PM, Piotr Wyderski wrote: > Richard Damon wrote: > >> My guess you would need to put that question to Xilinx Tech Support. >> The mask programmed boot loader may (likely) not have code to handle >> that sort of case. > > IMHO it would be enough to prevent it bumping the interface speed to x4. > Since it must start in x1 mode, the mode must certainly be supported. > > Best regards, Piotr But the Mask Programmed Boot Code may just hard wire send the command to shift to x4 mode, and then run assuming x4 mode. The support hardware list only list Quad-SPI parts (and not even all of them), so their design space may have been limited. That is why I suggest contacting Tech Support. We can just guess, they can look at the internals of the design and possibly know (or possibly just say it isn't documented, so it isn't available).Article: 160501
On 2018-02-18 lasselangwadtchristensen@gmail.com wrote in comp.arch.fpga: > Den søndag den 18. februar 2018 kl. 21.01.22 UTC+1 skrev Piotr Wyderski: >> lasselangwadtchristensen@gmail.com wrote: >> >> >> My memory of the part was that boot code mentioned is mask rom >> >> configured by Xilinx, which is run automatically on power on, and that >> >> boot loader determines the requested First Level Boot device, loads the >> >> program from it into the built in SRam, and executes it. >> >> >> >> I thought I remembered that the only flash cells was a very small block >> >> to configure the 'Secure Boot' mode, and to store the encryption key for >> >> secure boot. >> > >> > that is efuses, one time programmable >> >> Gents, that sounds nice, thanks. So I have a follow-up question: >> is it possible to force Zynq to use single DOUT SPI configuration? >> The manual says the chip supports QSPI and requires four DOUT wires, >> but QSPI starts in 1x mode by default, so I am confused. >> >> The reason is that I would like to configure the chip from >> a voting memory module in order to avoid configuration stream >> (and other persistent data) corruption and provide one memory >> chip failure tolerance. The x4 mode would imply fourfold >> replication of the voting circuitry and the bidirectional >> nature of DIN doesn't help either. The old good SPI protocol >> could be nicely covered by a single 74AC251 8:1 MUX. >> >> Best regards, Piotr > > https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QPSI-Boot-from-Legacy-1-Bit-SPI-Device/td-p/383065 -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) You know it's going to be a bad day when you want to put on the clothes you wore home from the party and there aren't any.Article: 160502
Richard Damon wrote: > My memory of the part was that boot code mentioned is mask rom > configured by Xilinx Roma locuta, it IS a mask-programmed ROM. Hereinafter there is no need for further speculations, Zynq is not leaky and hence usable in this application. I thought it might be useful for some of you. Best regards, PiotrArticle: 160503
VHDL + VUnit (https://vunit.github.io/index.html) Regards, LarsArticle: 160504
VHDL + VUnit (https://vunit.github.io/index.html) Regards, LarsArticle: 160505
VHDL for design. VHDL + UVVM (Universal VHDL Verification Methodology, Open source) for verification https://github.com/UVVM/UVVM_All Using VHDL with a good testbench architecture and a good infrastructure library allows very efficient verification. BTW: UVVM also comes with open source BFMs (Bus Functional Models) and VVCs (VHDL Verification Components) for interfaces like AIX4-lite, AXI4-stream, Avalon MM, UART, I2C, SPI.Article: 160506
Am Dienstag, 13. Februar 2018 00:51:07 UTC+1 schrieb Peter S: > What is the most efficient Xilinx family? I don't need embedded hard CPU, transceiver I/O, or anything but DSP hard blocks and basic logic. Why are you sticking to Xilinx now when you need low power? Maybe this answer helps also to exclude some Xilinx devices. You should also check Microsemi FPGA. They tend to be far smaller and providing less performance for high end than Xilinx and Altera, but have interessting power figures. As far as I know the lattice ICE40 has problems reaching similar low power performance than Igloo. But I never did a real case study to verify this statement. bye ThomasArticle: 160507
In case anybody missed it: https://www10.edacafe.com/nbc/articles/1/1569384/Microchip-Technology-Acquire-Microsemi Hans www.ht-lab.comArticle: 160508
On 3/3/18 4:28 AM, HT-Lab wrote: > In case anybody missed it: > > https://www10.edacafe.com/nbc/articles/1/1569384/Microchip-Technology-Acquire-Microsemi > > > Hans > www.ht-lab.com Well, it isn't final yet, the article says the Boards have approved it but it still needs shareholder approval and regulatory approvals, but sounds like it is expected to clear in the next couple of months.Article: 160509
On 03/03/2018 01:28 AM, HT-Lab wrote: > In case anybody missed it: > > https://www10.edacafe.com/nbc/articles/1/1569384/Microchip-Technology-Acquire-Microsemi > > > Hans > www.ht-lab.com Man, Microchip has really come out of nowhere these last few year; they definitely don't want to just be pidgeonholed into PIC anymore. On a larger note, is anyone else feeling like a good 2/3 of the companies you've been doing business with for years have been acquired in just the last few? Linear, National, Altera, Fairchild, Intersil, IRF, Avago, Freescale, and that's just off the very top of my head. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 160510
Rob Gaddi wrote: > On 03/03/2018 01:28 AM, HT-Lab wrote: >> In case anybody missed it: >> >> https://www10.edacafe.com/nbc/articles/1/1569384/Microchip-Technology- Acquire-Microsemi >> >> >> Hans >> www.ht-lab.com > > Man, Microchip has really come out of nowhere these last few year; they > definitely don't want to just be pidgeonholed into PIC anymore. > > On a larger note, is anyone else feeling like a good 2/3 of the > companies you've been doing business with for years have been acquired > in just the last few? Linear, National, Altera, Fairchild, Intersil, > IRF, Avago, Freescale, and that's just off the very top of my head. > Yes, consolidation has been going on for some time, not only in semis, but in other components as well. Tyco has bought out MANY of the connector manufacturers. JonArticle: 160511
What are thoughts on these two vendors goods? I like that they have cheap(er) PCIe options. My intended use case is to learn about HW and HDL development with an existing strong OS development background so I want to write device drivers to interface etc. Right now I'm leaning toward Lattice but I like that Microsemi is embracing RISC-V.Article: 160512
In article <p7ocvg$vj8$1@csiph.com>, kevin.bowling@kev009.com says... > > What are thoughts on these two vendors goods? I like that they have > cheap(er) PCIe options. My intended use case is to learn about HW and > HDL development with an existing strong OS development background so I > want to write device drivers to interface etc. > > Right now I'm leaning toward Lattice but I like that Microsemi is > embracing RISC-V. Kevin - I'm in the process of learning FPGA and the advice I would give is (general not just fpga advice - it's just my conclusions from starting this path myself recently:) : Dont start with manufacturers: Look for the best supported devices - look for the very best toolchain you can get - then look for a manufacturers forum (their OWN forum not some third party link) - then look around the internet to see how much public support you can find for the company (not a specific product) - next look for quality of supplied documentation. Then look for a range of development boards in your price range (and below - you dont need the most expensive to learn on - but be careful of 'garden shed' board manufacturers) Some sub $100 boards are great to learn on but go to a reputable supplier - dont buy from the manufacturer unless you are spending big sums.. Dont' fall for the high level design language approach - that's only worth looking at when you are fully conversant with the lower level. You need to be able to: 1. design - RTL knowledge is essential 2. simulate 3. synthesize etc can come later when needed. Ignore individual chip prices and speeds and features. Buy the best books you can get your hands on and read them. FPGA as you no doubt know is a much more complex subject than simple software writing. Good books help a lot - sadly there are very few 'good' books as far as I can see. If you have no electronics experience be prepared for some suprises. If you are experienced in electronics and software - be doubly prepared for twice as many suprises. (some good - some entertaining) If you plan to use it at all professionally - choose VHDL - dont be fooled into thinking otherwise - yes it's more specific - than the alternatives but that's exactly what you need when designing hardware. Verilog and the others may not be exactly 'sloppy' but there are good reasons governments demand VHDL - There is a big learning curve so dont waste it on something you can't use later. In short - look for a support network first - then worry about the chip details later. I hope thats helpful - to someone anyway. -- john ========================= http://johntech.co.uk =========================Article: 160513
> > VHDL for RTL (primarily FPGAs but ASIC in the past). VHDL + OSVVM for testbenches. > Same here. Even when not using OSVVM, I use VHDL primarly for my testbenches, sometimes with PSL when needed.Article: 160514
Hi,=20 I'm trying to process a Ethernet type package. Suppose if i have detected S= FD and now have a <1600Byte data. I'm extracting different package element(ds_addr,src_addr,etc) concatenatin= g them in a long shift register and at same time passing it to a fifo to bu= ffer and calculating crc32 which will take some clock cycles(xoring and shi= fting). Now if calculated CRC matched what is received, pass data to nxt st= age else rst fifo. =20 Is there a better technique for it? Thank-You in advance.Article: 160515
On 2018-03-12 12:02, yogesh tripathi wrote: > Hi, > > I'm trying to process a Ethernet type package. Suppose if i have detected SFD and now have a <1600Byte data. > > I'm extracting different package element(ds_addr,src_addr,etc) concatenating them in a long shift register and at same time passing it to a fifo to buffer and calculating crc32 which will take some clock cycles(xoring and shifting). Now if calculated CRC matched what is received, pass data to nxt stage else rst fifo. > > > Is there a better technique for it? > > Thank-You in advance. > Hi Calculate CRC on-the-fly together with incoming data. AdamArticle: 160516
On Monday, March 12, 2018 at 6:22:39 PM UTC+5:30, Adam G=C3=B3rski wrote: > On 2018-03-12 12:02, yogesh tripathi wrote: > > Hi, > >=20 > > I'm trying to process a Ethernet type package. Suppose if i have detect= ed SFD and now have a <1600Byte data. > >=20 > > I'm extracting different package element(ds_addr,src_addr,etc) concaten= ating them in a long shift register and at same time passing it to a fifo t= o buffer and calculating crc32 which will take some clock cycles(xoring and= shifting). Now if calculated CRC matched what is received, pass data to nx= t stage else rst fifo. > > =20 > >=20 > > Is there a better technique for it? > >=20 > > Thank-You in advance. > >=20 >=20 > Hi >=20 > Calculate CRC on-the-fly together with incoming data. >=20 > Adam Hi Adam, "Calculate CRC on-the-fly together with incoming data." , can you elaborat= e it a bit more. I'm getting a 8bit data in one clock cycle from the decoder. Now for crc i = need serial shift register.Article: 160517
Implement this transition function as your 8-bit data is coming in on each = cyle: https://en.wikipedia.org/wiki/Cyclic_redundancy_check#CRC-32_algorithm Or you could have a 2x clock for the inner loop to fit the table access, or= compute everything one byte per clock cycle by pipelining the accesses suc= h as: crc32_now =3D crc32_prev[23:0] XOR output_from_sram_one_cycle_delay lookup_sram_index_next =3D crc32_now[7:0] XOR data_from_packet crc32_prev =3D crc32_now Then make sure you handle the reset conditions on packet start, end of pack= et, etc. On Tuesday, March 13, 2018 at 12:05:15 AM UTC-4, yogesh tripathi wrote: > On Monday, March 12, 2018 at 6:22:39 PM UTC+5:30, Adam G=C3=B3rski wrote: > > On 2018-03-12 12:02, yogesh tripathi wrote: > > > Hi, > > >=20 > > > I'm trying to process a Ethernet type package. Suppose if i have dete= cted SFD and now have a <1600Byte data. > > >=20 > > > I'm extracting different package element(ds_addr,src_addr,etc) concat= enating them in a long shift register and at same time passing it to a fifo= to buffer and calculating crc32 which will take some clock cycles(xoring a= nd shifting). Now if calculated CRC matched what is received, pass data to = nxt stage else rst fifo. > > > =20 > > >=20 > > > Is there a better technique for it? > > >=20 > > > Thank-You in advance. > > >=20 > >=20 > > Hi > >=20 > > Calculate CRC on-the-fly together with incoming data. > >=20 > > Adam >=20 > Hi Adam, >=20 > "Calculate CRC on-the-fly together with incoming data." , can you elabor= ate it a bit more. > I'm getting a 8bit data in one clock cycle from the decoder. Now for crc = i need serial shift register.Article: 160518
On Mon, 12 Mar 2018 21:05:09 -0700 (PDT), yogesh tripathi <yogitripathi47@gmail.com> wrote: > I'm getting a 8bit data in one clock cycle from the decoder. Now for crc i = > need serial shift register. You have some options: 1. Use a precalculated table (rainbow table) for CRC. With 8 bit the size of the table is usually acceptable. 2. Use the 8x clock for the CRC calculating shift register (not recommended here). 3. Use a pipelined CRC calculation: The calc module is 8 times in parallel and you get the final result with eight clocks latency. BartArticle: 160519
In article <almarsoft.7981620793307616371@news.eternal-september.org>, Bart Fox <bartfox@gmx.net> wrote: >On Mon, 12 Mar 2018 21:05:09 -0700 (PDT), yogesh tripathi ><yogitripathi47@gmail.com> wrote: >> I'm getting a 8bit data in one clock cycle from the decoder. Now >for crc i = >> need serial shift register. >You have some options: >1. Use a precalculated table (rainbow table) for CRC. With 8 bit the >size of the table is usually acceptable. >2. Use the 8x clock for the CRC calculating shift register (not >recommended here). >3. Use a pipelined CRC calculation: The calc module is 8 times in >parallel and you get the final result with eight clocks latency. Table methods are very likely NOT the correct solution for FPGA implementations. Those methods are tuned for SW solutions. CRCs in hardware are actually quite easy / low resources. Shifting through the 8 bits in one clock cycle will probably work just fine. There's online websites that have "CRC" calculators which can do some of this work for you. But I find just coding up the algorithm in verilog / VHDL to be more compact and clear. If that doesn't work - i.e. you're not hitting you're desired clock frequencies - then Bart's suggestion of pipelining the calc is valid. That can be a little trickier, but still doable. I don't think you'll need to go this far, unless you're trying to hit some high clock rates. Regards, MarkArticle: 160520
On 13/03/2018 04:05, yogesh tripathi wrote: > On Monday, March 12, 2018 at 6:22:39 PM UTC+5:30, Adam Górski wrote: >> On 2018-03-12 12:02, yogesh tripathi wrote: >>> Hi, >>> >>> I'm trying to process a Ethernet type package. Suppose if i have detected SFD and now have a <1600Byte data. >>> >>> I'm extracting different package element(ds_addr,src_addr,etc) concatenating them in a long shift register and at same time passing it to a fifo to buffer and calculating crc32 which will take some clock cycles(xoring and shifting). Now if calculated CRC matched what is received, pass data to nxt stage else rst fifo. >>> >>> >>> Is there a better technique for it? >>> >>> Thank-You in advance. >>> >> >> Hi >> >> Calculate CRC on-the-fly together with incoming data. >> >> Adam > > Hi Adam, > > "Calculate CRC on-the-fly together with incoming data." , can you elaborate it a bit more. > I'm getting a 8bit data in one clock cycle from the decoder. Now for crc i need serial shift register. Not necessarily, have a look at: http://www.easics.com/webtools/crctool I've used this, albeit a few years ago and the website has changed since. If I recall you have to invert and swap the bit order to get the correct CRC. I used a simulator to check the permutations until I got it right. If you have 8bit data you can generate the CRC on the fly at the same rate. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 160521
On Wednesday, March 14, 2018 at 1:18:40 AM UTC+5:30, Mike Perkins wrote: > On 13/03/2018 04:05, yogesh tripathi wrote: > > On Monday, March 12, 2018 at 6:22:39 PM UTC+5:30, Adam G=C3=B3rski wrot= e: > >> On 2018-03-12 12:02, yogesh tripathi wrote: > >>> Hi, > >>> > >>> I'm trying to process a Ethernet type package. Suppose if i have dete= cted SFD and now have a <1600Byte data. > >>> > >>> I'm extracting different package element(ds_addr,src_addr,etc) concat= enating them in a long shift register and at same time passing it to a fifo= to buffer and calculating crc32 which will take some clock cycles(xoring a= nd shifting). Now if calculated CRC matched what is received, pass data to = nxt stage else rst fifo. > >>> =20 > >>> > >>> Is there a better technique for it? > >>> > >>> Thank-You in advance. > >>> > >> > >> Hi > >> > >> Calculate CRC on-the-fly together with incoming data. > >> > >> Adam > >=20 > > Hi Adam, > >=20 > > "Calculate CRC on-the-fly together with incoming data." , can you ela= borate it a bit more. > > I'm getting a 8bit data in one clock cycle from the decoder. Now for cr= c i need serial shift register. >=20 > Not necessarily, have a look at: > http://www.easics.com/webtools/crctool >=20 > I've used this, albeit a few years ago and the website has changed since. >=20 > If I recall you have to invert and swap the bit order to get the correct= =20 > CRC. I used a simulator to check the permutations until I got it right. >=20 > If you have 8bit data you can generate the CRC on the fly at the same rat= e. >=20 >=20 > --=20 > Mike Perkins > Video Solutions Ltd > www.videosolutions.ltd.uk Thank-You Mike. The link gives a provide a HDL package which is basically a Parallel LFSR. = You know any related text how to generate a custom LFSR for these CRC ,just= for better understanding.Article: 160522
>>> Hi, >>> >>> I'm trying to process a Ethernet type package. Suppose if i have detected SFD and now have a <1600Byte data. >>> >>> I'm extracting different package element(ds_addr,src_addr,etc) concatenating them in a long shift register and at same time passing it to a fifo to buffer and calculating crc32 which will take some clock cycles(xoring and shifting). Now if calculated CRC matched what is received, pass data to nxt stage else rst fifo. >>> >>> >>> Is there a better technique for it? >>> >>> Thank-You in advance. >>> >> >> Hi >> >> Calculate CRC on-the-fly together with incoming data. >> >> Adam > > Hi Adam, > > "Calculate CRC on-the-fly together with incoming data." , can you elaborate it a bit more. > I'm getting a 8bit data in one clock cycle from the decoder. Now for crc i need serial shift register. > So look for CRC implementation able to process 8bits ( byte ) in single clock and store data in same time to fifo and to CRC unit. Hint: Online CRC VHDL generator. There is many. Best regards Adam GórskiArticle: 160523
On 15/03/2018 11:28, yogesh tripathi wrote: > On Wednesday, March 14, 2018 at 1:18:40 AM UTC+5:30, Mike Perkins > wrote: >> On 13/03/2018 04:05, yogesh tripathi wrote: >>> On Monday, March 12, 2018 at 6:22:39 PM UTC+5:30, Adam Górski >>> wrote: >>>> On 2018-03-12 12:02, yogesh tripathi wrote: >>>>> Hi, >>>>> >>>>> I'm trying to process a Ethernet type package. Suppose if i >>>>> have detected SFD and now have a <1600Byte data. >>>>> >>>>> I'm extracting different package >>>>> element(ds_addr,src_addr,etc) concatenating them in a long >>>>> shift register and at same time passing it to a fifo to >>>>> buffer and calculating crc32 which will take some clock >>>>> cycles(xoring and shifting). Now if calculated CRC matched >>>>> what is received, pass data to nxt stage else rst fifo. >>>>> >>>>> >>>>> Is there a better technique for it? >>>>> >>>>> Thank-You in advance. >>>>> >>>> >>>> Hi >>>> >>>> Calculate CRC on-the-fly together with incoming data. >>>> >>>> Adam >>> >>> Hi Adam, >>> >>> "Calculate CRC on-the-fly together with incoming data." , can you >>> elaborate it a bit more. I'm getting a 8bit data in one clock >>> cycle from the decoder. Now for crc i need serial shift >>> register. >> >> Not necessarily, have a look at: >> http://www.easics.com/webtools/crctool >> >> I've used this, albeit a few years ago and the website has changed >> since. >> >> If I recall you have to invert and swap the bit order to get the >> correct CRC. I used a simulator to check the permutations until I >> got it right. >> >> If you have 8bit data you can generate the CRC on the fly at the >> same rate. >> >> >> -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk > > Thank-You Mike. The link gives a provide a HDL package which is > basically a Parallel LFSR. You know any related text how to generate > a custom LFSR for these CRC ,just for better understanding. I looked into this a long while ago and gave up! A LFSR is a simple concept in it's own right but I didn't have time to decipher a Parallel LFSR. I made the choice of using the result rather than spend time trying to understand something I would only use once in a long while. I'm sure there are proof and theorems on the 'net somewhere! -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 160524
On Tue, 13 Mar 2018 19:28:17 -0000 (UTC), gtwrek@sonic.net (gtwrek) wrote: > Table methods are very likely NOT the correct solution for FPGA > implementations. Those methods are tuned for SW solutions. Sorry for respeak.Of course is the usage of a lookup-table a valid design technic for FPGAs. Maybe not in the range of megabytes, but e.g. for 8 bit input and 8 bit output it's very acceptable. One example: a low fidelity DDS usually use a small ROM with a sine table... Bart Fox
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z