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 27 Mrz., 17:41, Austin Lesea <aus...@xilinx.com> wrote: > JJ, > > If the part is connected properly, you will see the proper signal on INIT_B. > > INIT_B will go high while the devices cleans out, and gets ready to try > to configure, and then it will go low when cleanout is done before it > starts to configure. If there is no configuration device present, then > this sequence of INIT_B lets you know that the device is ready and waiting. > > Also, if a master mode is selected, the CCLK pin should be running. > > See page 56 of 280: > > http://direct.xilinx.com/bvdocs/userguides/ug332.pdf > > Austin Thank you Austin for your help. I finally got to program the FPGA. The problem was on the programmer I used: Xilinx Parallel Cable 3. The strange problem with this cable has haunted me since I built it. I described the problem here: http://groups.google.at/group/comp.arch.fpga/browse_thread/thread/931f54aee8faca51/6a97e6e07f67e1b4?hl=de#6a97e6e07f67e1b4 JJArticle: 117326
On Mar 28, 11:12 am, jid...@hotmail.com wrote: > Hi, > > To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3 > XCS400) at the same time, I decided as a programmer to use the Xilinx > Parallel Cable III. I implemented the programmer 100% the same as > found in Xilinx's website (http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html). > The programmer worked, but not without problems. For programming the > Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable > from the LPT port to Programmer was 20cm long and from the programmer > to the uC/FPGA board was not more than 10 cm. > The problem related with this programmer were verification errors, i.e > the PC can't program or read properly from the board. The interesting > thing is how these verification problem came up. > In the morning when I turn the PC and Board on, these verification > errors are a lot. When the code that I want to download is big, its > impossible to program the FPGA/uC, for small codes it works but after > many tries. After 10 tries or so, the programming works correct and > no verification errors no matter how many times I try to download the > code or how big the code is, and this without even touching a thing on > the hardware!!! > > Since this problem applies to more than one board, I assume the > problem must lay on the programmer itself. My explanation is that > maybe the buffer IC's get hot or something...I really don't know. > I want to know if there is anyone who has had problems with this > programmer cable. > > Thank You, > JJ I'm doing exactly the same, but I'm using the Digilent Parallel JTAG3 cable ($12 http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable) Impact 6.3 to program my Spartan3-1000, and avrdude to program my ATmega64. I had problems in the past when I had some noisy power supplies in the lab and got mysterious errors, sometimes I had to turn off the noisy power supply to make my JTAG work :) ZoltanArticle: 117327
Martin Thompson wrote:
> "Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:
>
>> Until my larger designs are sufficiently advanced to start producing
>> meaningful simulation results (I call this the approximation phase), I
>> am more interested in tracking resource utilization and static timing
>> evolution than correctness: achieving absolute correctness in the
>> first pass (the one most susceptible to typos and syntax errors) is
>> useless if the implementation fails to meet target timings or exceeds
>> the logic budget. It is during these passes that XST&all die on me the
>> most and Modelsim as a simulation tool is irrelevant - that's why it
>> took me so long to think of using it as a syntax checker.
>
> But if you make a trivial error in your design, won't the optimiser
> chuck lots of stuff out and make it look much better than it is?
> You'll never know until you simulate...
When the optimizer chucks out lots of stuff, it usually spits out
truckloads of warnings about unconnected signals being trimmed, never
changing ("replaced by logic") or equivalent to some other net. Some of
these trimmed signals are expected (is there a simple and inexpensive way
to quietly drop multiplier LSBs when doing fixed-point maths?) but the rest
are good indicators of missing stuff.
Since I do not wish to spend much time on control logic during the
approximation phase, I simply connect the N control signals to an N-bits
PRNG with a few IOBs blended in to prevent synthesis from simplifying the
dummy control logic and everything else thereafter. Once the
data/processing pipeline is in place and looks good, I can start
implementing and optimizing the real control logic using simulations - I
usually try to save as much of the control logic as possible for last since
relatively minor data path refinements can have a major impact on the
control logic and optimization opportunities... I am lazy so I try to avoid
moving targets whenever possible.
Article: 117328JJ, Sounds like you have a signal integrity problem with the cable and the interface. I suggest using Hyperlynx from Mentor to troubleshoot, or read up on SI. http://www.xilinx.com/products/design_resources/signal_integrity/ AustinArticle: 117329
On 28 Mrz., 18:25, "zcsizma...@gmail.com" <zcsizma...@gmail.com> wrote: > On Mar 28, 11:12 am, jid...@hotmail.com wrote: > > > > > Hi, > > > To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3 > > XCS400) at the same time, I decided as a programmer to use the Xilinx > > Parallel Cable III. I implemented the programmer 100% the same as > > found in Xilinx's website (http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html). > > The programmer worked, but not without problems. For programming the > > Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable > > from the LPT port to Programmer was 20cm long and from the programmer > > to the uC/FPGA board was not more than 10 cm. > > The problem related with this programmer were verification errors, i.e > > the PC can't program or read properly from the board. The interesting > > thing is how these verification problem came up. > > In the morning when I turn the PC and Board on, these verification > > errors are a lot. When the code that I want to download is big, its > > impossible to program the FPGA/uC, for small codes it works but after > > many tries. After 10 tries or so, the programming works correct and > > no verification errors no matter how many times I try to download the > > code or how big the code is, and this without even touching a thing on > > the hardware!!! > > > Since this problem applies to more than one board, I assume the > > problem must lay on the programmer itself. My explanation is that > > maybe the buffer IC's get hot or something...I really don't know. > > I want to know if there is anyone who has had problems with this > > programmer cable. > > > Thank You, > > JJ > > I'm doing exactly the same, but I'm using the Digilent Parallel JTAG3 > cable ($12http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Ca...) > Impact 6.3 to program my Spartan3-1000, and avrdude to program my > ATmega64. > I had problems in the past when I had some noisy power supplies in the > lab and got mysterious errors, sometimes I had to turn off the noisy > power supply to make my JTAG work :) > > Zoltan Glad to hear that I am not the only one who has a problem with this programmer!! I thought at the beginning also it has to be some kind of interference from somewhere, but as I said, I usually change nothing, just click many times until it works, and when it does, it works without any problems for hours.But before i reach this phase, it really gives me headach :( JJ JJArticle: 117330
<jidan1@hotmail.com> wrote in message news:1175098335.158323.203250@n59g2000hsh.googlegroups.com... > Hi, > > To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3 > XCS400) at the same time, I decided as a programmer to use the Xilinx > Parallel Cable III. I implemented the programmer 100% the same as > found in Xilinx's website ( > http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html). > The programmer worked, but not without problems. For programming the > Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable > from the LPT port to Programmer was 20cm long and from the programmer > to the uC/FPGA board was not more than 10 cm. > The problem related with this programmer were verification errors, i.e > the PC can't program or read properly from the board. The interesting > thing is how these verification problem came up. > In the morning when I turn the PC and Board on, these verification > errors are a lot. When the code that I want to download is big, its > impossible to program the FPGA/uC, for small codes it works but after > many tries. After 10 tries or so, the programming works correct and > no verification errors no matter how many times I try to download the > code or how big the code is, and this without even touching a thing on > the hardware!!! > > Since this problem applies to more than one board, I assume the > problem must lay on the programmer itself. My explanation is that > maybe the buffer IC's get hot or something...I really don't know. > I want to know if there is anyone who has had problems with this > programmer cable. > > > Thank You, > JJ The newer Xilinx programming cables (Parallel Cable IV, Platform Cable USB) use comparators rather than simple buffers to establish proper voltage levels from the VREF pin connected to the programmer and VCC supplied eternally (keyboard passthrough or USB). The VCC supplied to the Parallel Cable III powers the buffers; the result is poor signal levels on low voltage interfaces. I had a 2.5V JTAG interface I could not get working when using the Parallel Cable III powered by 2.5V. Just by increasing the VCC to 3.3V, I was able to keep decent logic levels and get the interface working. But I never trusted it; if I got a good result I was happy. The convenience and (decent) reliability of the Platform Cable USB is well worth the price in my mind. - John_HArticle: 117331
Hi all. I am experiencing a very annoying problem while trying to run a sequential fault simulation with Tetramax, using external patterns saved (via a VCD dump) from a back-annotated simulation done in ModelSim. The problem is that when I load the VCD dump file in Tetramax and simulate it, the tool produces wrong simulation results, exhibiting an akward behavior. The caption in the following link explains the whole situation: h**p://images.elektroda.net/37_1175093373.jpg ****[Upper part of image: Modelsim 5.8b simulation - Results: OK, as expected]**** Notice the timing of the clocks PAD_EMTCK and PAD_CLK. At the beginning they have periods of 40 and 20 ns, respectively. Then, @ 27,240ns, signal PAD_SCAN_EN goes up and PAD_CLK assumes also a 40 ns period (the other clock remains unaffected). Notice also the 40ns-wide pulses appearing on signals PAD_SCAN_IN1...3. ****[Lower part of image: Tetramax Z-2007.03 simulation - Results: WRONG]**** This is Tetramax's simulation as obtained through the reading of modelsim's vcd dump through the following command:"set patterns external my_dump.vcd -sensitive -strobe period 40 ns -strobe offset 37 ns" (note that this command implies the sampling of the test patterns at periodic intervals of 40ns, with a suitable offset of 37ns that should allow for an appropriate sampling of stable values in all waveforms). Notice now the awful part: at the beginning Tetramax seems to get it right, and defines the test patterns at regular intervals 40ns apart. But then misfortune happens: after the edge of PAD_SCAN_EN, Tetramax incredibily does two wrong things: 1. Contrary of what was specified in the "set patterns" command, it starts to sample the test patterns EVERY 20ns!!!! 2. It starts mis-simulating everything: the periods of both clocks switch to 20ns, the pulses appearing in PAD_SCAN_IN1...3 are 20ns- wide ,etc. Therefore, since the dumped file is not appropiately simulated by Tetramax, I cannot perform the desired fault simulation, which I desperately need. I would be the most grateful if anybody could please give a clue to what is going wrong here. Why doesn't Tmax respect the 40ns-period samping? Am I missing something in the "set patterns" command? I have struggled for 2 weeks with this problem without success. I have even tried using other versions of Tmax, and also giving different values to the "offset" parameter, without any luck. I have also verified the vcd dump file's correctness with a third tool, with positive results. Any suggestions are really, really welcome!!! Thanks in advance!!! Regards, JL.Article: 117332
On 28 Mrz., 18:55, "John_H" <newsgr...@johnhandwork.com> wrote: > <jid...@hotmail.com> wrote in message > > news:1175098335.158323.203250@n59g2000hsh.googlegroups.com... > > > > > Hi, > > > To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3 > > XCS400) at the same time, I decided as a programmer to use the Xilinx > > Parallel Cable III. I implemented the programmer 100% the same as > > found in Xilinx's website ( > >http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html). > > The programmer worked, but not without problems. For programming the > > Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable > > from the LPT port to Programmer was 20cm long and from the programmer > > to the uC/FPGA board was not more than 10 cm. > > The problem related with this programmer were verification errors, i.e > > the PC can't program or read properly from the board. The interesting > > thing is how these verification problem came up. > > In the morning when I turn the PC and Board on, these verification > > errors are a lot. When the code that I want to download is big, its > > impossible to program the FPGA/uC, for small codes it works but after > > many tries. After 10 tries or so, the programming works correct and > > no verification errors no matter how many times I try to download the > > code or how big the code is, and this without even touching a thing on > > the hardware!!! > > > Since this problem applies to more than one board, I assume the > > problem must lay on the programmer itself. My explanation is that > > maybe the buffer IC's get hot or something...I really don't know. > > I want to know if there is anyone who has had problems with this > > programmer cable. > > > Thank You, > > JJ > > The newer Xilinx programming cables (Parallel Cable IV, Platform Cable USB) > use comparators rather than simple buffers to establish proper voltage > levels from the VREF pin connected to the programmer and VCC supplied > eternally (keyboard passthrough or USB). The VCC supplied to the Parallel > Cable III powers the buffers; the result is poor signal levels on low > voltage interfaces. > > I had a 2.5V JTAG interface I could not get working when using the Parallel > Cable III powered by 2.5V. Just by increasing the VCC to 3.3V, I was able > to keep decent logic levels and get the interface working. But I never > trusted it; if I got a good result I was happy. The convenience and > (decent) reliability of the Platform Cable USB is well worth the price in my > mind. > > - John_H I used 3.3V JTAG interface since the beginning, and also since the beginning I had problems with it. I think part of the problem might be in the buffer itself. The input voltage at the buffer(74HC125) used there, according to the data sheet, should be max. VCC+1.5. And if you are using VCC=3.3V or 2.5V, the high level voltage coming from the LPT(5V) will be exceeding the max. input voltage. A series resistor was used to limit the current going through the clamp didoe, however the signal might have got distorted because of that.I have also thought about using Schmitt-triggers instead of buffers. At the end I built the exact circuit posted in xilinx website, because I thought the Xilinx team knows better than me. But that circuit has caused me a lot of problems and it seems I am not the only one! JJArticle: 117333
On Mar 26, 10:54 pm, "veeresh" <veeresh8...@yahoo.co.in> wrote: > Hello Sir, > > I'm trying to simulate a design involving Block RAM implemented > using core generator. > Please consider the example "Dual Port Block RAM v6.1" at Hi Vereesh, The problem you are running into is because the version of the MXE libraries are not matching with your ISE version. Please ensure that the two match. Ideally you want to use ISE 7.1i SP3 and the MXE libraries for SP3 and the IPUpdate and then try this again. It will work correctly. Also note that when you download the libraries it says that the files have to be installed in order. What this means is that always download the latest library for that ISE version based on the time stamp on the download page. Thanks Duth > http://www.xilinx.com/support/software/coregen/71i_coregen_examples.htm > > I generated an empty test bench for this design. I'm able to do PARSimulationon virtex 2. When I tried same on virtex 4, Modelsim XE > simulator is giving error message saying two generics"en_ecc_read", > and "en_ecc_write" are not defined. > > My tool set is: > Tool : ISE 7.1 > Simulator : Modelsim XE III/Starter 6.0a > > Can you please help me to find the reason? > > Thanks and Regards, > VeereshArticle: 117334
jidan1@hotmail.com wrote: > > I used 3.3V JTAG interface since the beginning, and also since the > beginning I had problems with it. I think part of the problem might be > in the buffer itself. The input voltage at the buffer(74HC125) used > there, according to the data sheet, should be max. VCC+1.5. And if you > are using VCC=3.3V or 2.5V, the high level voltage coming from the > LPT(5V) will be exceeding the max. input voltage. A series resistor > was used to limit the current going through the clamp didoe, however > the signal might have got distorted because of that.I have also > thought about using Schmitt-triggers instead of buffers. At the end I > built the exact circuit posted in xilinx website, because I thought > the Xilinx team knows better than me. But that circuit has caused me a > lot of problems and it seems I am not the only one! I've always stuck two (because they are inverting) 74HCT14 Schmidt triggers in there, and have no problems with long parallel cables on a number of different boards and computers.Article: 117335
Hi, I need to chose between the Altera Stratix II GX or Stratix III GX and some Xilinx Virtex5 FPGA for an implementation of gigabit interface into a multi DSP system. Could you suggest pro and cons between Altera and Xilinx (or maybe others) for such design ? If I'm trying to compare Altera with Xilinx FPGA based on those websites, both are telling is better than the other. Maybe you know and independent comparison table between those two ? thank you, VasileArticle: 117336
Vasile, Virtex 5 LX and LXT, SXT, is in production on almost all devices, and available now. What isn't in production is sampling right now (and available). http://www.xilinx.com/onlinestore/silicon/online_store_v5.htm The serial transceivers are the lowest power of any (if that is important to you). We also have at least 30 serial transceiver standards tested and their characterization reports available (XAUI, PCI express, gigabit ethernet, fibrechannel, PCIe, HDSDI, etc. etc...). The last ten or so standards characterization reports are being finished as we speak. For the serial transceivers, we have over 400 FAEs worldwide, with about 11 RocketChips(tm) Labs spread around the world where we provide all the necessary equipment for our customers to work with our MGTs, or to learn about the signal integrity challenges on these interfaces. Product+Features+Characterization+Support=Success. AustinArticle: 117337
On 28 Mrz., 21:16, Duane Clark <junkm...@junkmail.com> wrote: > jid...@hotmail.com wrote: > > > I used 3.3V JTAG interface since the beginning, and also since the > > beginning I had problems with it. I think part of the problem might be > > in the buffer itself. The input voltage at the buffer(74HC125) used > > there, according to the data sheet, should be max. VCC+1.5. And if you > > are using VCC=3.3V or 2.5V, the high level voltage coming from the > > LPT(5V) will be exceeding the max. input voltage. A series resistor > > was used to limit the current going through the clamp didoe, however > > the signal might have got distorted because of that.I have also > > thought about using Schmitt-triggers instead of buffers. At the end I > > built the exact circuit posted in xilinx website, because I thought > > the Xilinx team knows better than me. But that circuit has caused me a > > lot of problems and it seems I am not the only one! > > I've always stuck two (because they are inverting) 74HCT14 Schmidt > triggers in there, and have no problems with long parallel cables on a > number of different boards and computers. May I ask why you used inverting and not non-inverting schmitt- triggers? I assume if you used inverting schmitt-triggers you would have to change the programmer software to allow these inverted signals to be understandable. JJArticle: 117338
On 28 Mrz., 22:30, jid...@hotmail.com wrote: > On 28 Mrz., 21:16, Duane Clark <junkm...@junkmail.com> wrote: > > > > > jid...@hotmail.com wrote: > > > > I used 3.3V JTAG interface since the beginning, and also since the > > > beginning I had problems with it. I think part of the problem might be > > > in the buffer itself. The input voltage at the buffer(74HC125) used > > > there, according to the data sheet, should be max. VCC+1.5. And if you > > > are using VCC=3.3V or 2.5V, the high level voltage coming from the > > > LPT(5V) will be exceeding the max. input voltage. A series resistor > > > was used to limit the current going through the clamp didoe, however > > > the signal might have got distorted because of that.I have also > > > thought about using Schmitt-triggers instead of buffers. At the end I > > > built the exact circuit posted in xilinx website, because I thought > > > the Xilinx team knows better than me. But that circuit has caused me a > > > lot of problems and it seems I am not the only one! > > > I've always stuck two (because they are inverting) 74HCT14 Schmidt > > triggers in there, and have no problems with long parallel cables on a > > number of different boards and computers. > > May I ask why you used inverting and not non-inverting schmitt- > triggers? I assume if you used inverting schmitt-triggers you would > have to change the programmer software to allow these inverted signals > to be understandable. > > JJ ...or did you actually mean you used two inverted schitt-triggers becuase you didn't have one non-inverted schmitt-trigger :)Article: 117339
Ben > "Jim Lewis" <jim@synthworks.com> wrote in message > news:130it10cdc7ocbf@corp.supernews.com... > >> Please also read my paper on Accellera VHDL standard 3.0. Read up >> on the unary usage of operators such as XOR. >> Unfortunately due to overloading it will need a type qualifier, but >> you will be able to use it as: >> >>>> y_xor(0) <= XOR std_logic_vector'( x(1), x(2), x(3), x(5), x(8), >>>> x(9), x(11), x(14), >>>> x(17), x(18), x(19), x(21), x(24), x(25), x(27), >>>> x(30), x(32), x(36), >>>> x(38), x(39), x(42), x(44), x(45), x(47), x(48), >>>> x(52), x(54), x(55), >>>> x(58), x(60), x(61), x(63) ); > > Or I think I'd prefer: > > y_xor(0) <= xor (x and X"B4D1B4D14B2E4B2E"); > > Because it's much less typing. > I like it. Just if it was more readable. JimArticle: 117340
In news:1175034224.021941.188430@o5g2000hsb.googlegroups.com timestamped 27 Mar 2007 15:23:44 -0700, "Andy Peters" <google@latke.net> posted: "[..] > An extra semicolumn at the wrong place can crash XST but these are often > hard to spot since any other programming language would silently accept > them. I take it that you don't simulate much, if at all ... > Over the last two or three years, I wasted over a month hunting down > syntax-induced crashes, about a week of it last summer because XST got > confused while processing BRAM inferences... it took me a few days to > figure out the link between crashes and memory inferences and many more > tweaking the inference until I got what I wanted without crashing XST or MAP. > > The last time I ran into simple syntax errors I was unable to spot within > 2-3 minutes, I simply ran the thing through ModelSim's compiler... both a > fair bit faster and much more reliable. you should have used ModelSim FIRST !" That is not a good enough excuse.Article: 117341
jidan1@hotmail.com wrote: > > ...or did you actually mean you used two inverted schitt-triggers > becuase you didn't have one non-inverted schmitt-trigger :) > Yep, thats what I meant ;)Article: 117342
On 28 Mrz., 22:49, Duane Clark <junkm...@junkmail.com> wrote: > jid...@hotmail.com wrote: > > > ...or did you actually mean you used two inverted schitt-triggers > > becuase you didn't have one non-inverted schmitt-trigger :) > > Yep, thats what I meant ;) LOL...you might have not known this, but by using two schmitt-triggers (rather than one) you have made the programmer more noise immune! Do you still have the schematic for this circuit?Article: 117343
"vasile" <piclist9@gmail.com> wrote in message
news:1175110434.467891.112950@n59g2000hsh.googlegroups.com...
> Hi,
>
> I need to chose between the Altera Stratix II GX or Stratix III GX and
> some Xilinx Virtex5 FPGA for an implementation of gigabit interface
> into a multi DSP system.
>
> Could you suggest pro and cons between Altera and Xilinx (or maybe
> others) for such design ?
> If I'm trying to compare Altera with Xilinx FPGA based on those
> websites, both are telling is better than the other.
> Maybe you know and independent comparison table between those two ?
>
> thank you,
> Vasile
Do you need the raw power and size of those devices or do you long for
something more cost effective do do generic workhorse processing at decent
speeds and sizes? If so, consider the Lattice ECP2M series as well. They
may also have the lowest power transceivers in the industry:
Lattice:
3.125Gbps Embedded SERDES (ECP2M only)
Low 100mW power per channel
Xilinx:
Flexible SERDES with 100 Mbps-to-3.2 Gbps operating range supports all
popular protocols
Lowest power consumption in the industry: less than 100 mW per channel
at 3.2 Gbps
(shall we say 99.99 mW?)
The Lattice devices may not be fancy. They are used in quads rather than
trying to divide the functionality into smaller increments. But if what you
need is the raw bandwidth without super-extreme processing in between,
consider the outsider.
In my opinion, the ECP2M product has given Lattice a strong leg up on the
competition for a strong range of price/performance devices.
The points that are imprtant to some may not be important to others. Are
you concerned with:
Power? (Is >100 mW a problem?)
Speed? (Is 3.125Gb/s enough?)
Cost? (Whoa)
Flexibility? (How much granularity? # of independent channels? Channel
width?)
Device size? (How many LEs/LUTs will you need? RAM?)
Multiplier/DSPblock functionality? (Are there features that tip the
balance)
Logic speed? (Do you need 200 MHz or 500 MHz? Simple or complex paths?)
Clocking? (Do the devices support your clock source cleanly?)
I haven't seen a good apples-to-apples comparison becasue these choices and
concerns tend to make analysis less obvious.
- John_H
Article: 117344On Mar 28, 11:21 am, "Oli Charlesworth" <c...@olifilth.co.uk> wrote: > On Mar 28, 3:36 pm, "news reader" <newsrea...@google.com> wrote: > > > > > In my interleaver design for FPGA, I am using an external SDRAM for data > > storage. > > > The clock cycles required to write a frame into the RAM and read a frame > > back to error correction unit ain't enough. > > > The interleaver has 40 rows, which contain 200 * 0, 1, ...39 pieces of data. > > And one row of the RAM contains 256 data. The write/read pointers are > > increased by 200*i or decreased by 200*i (0<i<39) for each write/read > > operation. > > > As a result, nearly everytime I write one data or read one data, I have to > > go > > through a "open a new row, write or read 1 data, close the row" cycle. To > > open > > a row and close it, the memory requires some 10 clock cycles. > > > How is it possible to design it in such a way that memory write is in > > sequential > > order? That is, when a new frame arrives, I write into the RAM column by > > until current row is filled, then open the next row. > > > I may have to read in a random access, but I can save a lot of clock cycles > > in > > the memory write. > > > FYI, my resources is some RTL logic and an SDRAM. The design can be made > > with the FPGA's LUTs, but i don't own the resource. > > If you write out by hand the order in which data comes out of a depth- > N interleaver, you should be able to spot the pattern (it's really not > a very complicated pattern...). > > You can then just apply this pattern to the read pointer, letting you > store your data in the original (sequential) order. In other words, > the interleaving is done during the read operation. > > However, the read access pattern will be just as "random" as the write > access pattern was in your original design. So unless your SDRAM's > read cycle is shorter than its write cycle, this won't save you any > time. > > -- > Oli I'm not sure how much it would help in your application unless your interleave factor is constant, but using the 4 banks of the SDRAM is generally a faster way to deal with high-speed data than attempting to locate all data in a single row. SDRAM was designed such that the row activate and precharge can be "buried" behind other operations when multiple banks are used. So in essence if you can order your storage such that each new data comes from a different bank in the SDRAM you can cut your cycle time down significantly. Using the minimum burst size (assuming you don't need more than one word of data at a time) and read with autoprecharge (to avoid the additional command to "close" the row) you can get down to 2 cycles per read if you rotate through all four banks. A control sequence for a regular rotation through 4 banks might look like: --- Startup section with some wasted cycles --- Activate Row in Bank 0 NOP Activate Row in Bank 1 NOP Activate Row in Bank 2 --- Continuous high-bandwidth section Read Col in Bank 0 with autoprecharge Activate Row in Bank 3 Read Col in Bank 1 with autoprecharge Activate Row in Bank 0 Read Col in Bank 2 with autoprecharge Activate Row in Bank 1 Read Col in Bank 3 with autoprecharge Activate Row in Bank 2 Read Col in Bank 0 with autoprecharge Activate Row in Bank 3 Read Col in Bank 1 with autoprecharge Activate Row in Bank 0 Read Col in Bank 2 with autoprecharge Activate Row in Bank 1 Read Col in Bank 3 with autoprecharge Activate Row in Bank 2 Read Col in Bank 0 with autoprecharge Activate Row in Bank 3 Read Col in Bank 1 with autoprecharge --- Closing section with some wasted cycles NOP Read Col in Bank 2 with autoprecharge NOP Read Col in Bank 3 with autoprecharge Note that the mid-section can be repeated ad-naseum allowing unlimited access length at this bandwidth. Also note that each access includes its own Row and Column so other than the bank restriction the order can be truly random. HTH, GaborArticle: 117345
jidan1@hotmail.com wrote: > On 28 Mrz., 22:49, Duane Clark <junkm...@junkmail.com> wrote: >> jid...@hotmail.com wrote: >> >>> ...or did you actually mean you used two inverted schitt-triggers >>> becuase you didn't have one non-inverted schmitt-trigger :) >> Yep, thats what I meant ;) > > LOL...you might have not known this, but by using two schmitt-triggers > (rather than one) you have made the programmer more noise immune! Do > you still have the schematic for this circuit? > I originally got the circuit from someone here in this group (sorry, I forgot who). Anyway, here is a 60KB pdf: http://www.leewardfpga.com/par_jtag.pdf As you can see, if I have room on my circuit board, I simply stick this circuit and a connector on the board, and run a plain parallel cable between the computer and the board.Article: 117346
On 28 Mrz., 23:44, Duane Clark <junkm...@junkmail.com> wrote: > jid...@hotmail.com wrote: > > On 28 Mrz., 22:49, Duane Clark <junkm...@junkmail.com> wrote: > >> jid...@hotmail.com wrote: > > >>> ...or did you actually mean you used two inverted schitt-triggers > >>> becuase you didn't have one non-inverted schmitt-trigger :) > >> Yep, thats what I meant ;) > > > LOL...you might have not known this, but by using two schmitt-triggers > > (rather than one) you have made the programmer more noise immune! Do > > you still have the schematic for this circuit? > > I originally got the circuit from someone here in this group (sorry, I > forgot who). Anyway, here is a 60KB pdf: > > http://www.leewardfpga.com/par_jtag.pdf > > As you can see, if I have room on my circuit board, I simply stick this > circuit and a connector on the board, and run a plain parallel cable > between the computer and the board. Thanks for sharing the schematics! Hmm...the TDO and voltage sense line are the exactly the same as orginally posted by Xilinix. For the other JTAG lines (TMS, TCK, TDI), two schmitt-triggers and a buffer were used to increase noise immunity. Thats a little bit too many components for my taste, but seems to be reliable.Article: 117347
<jidan1@hotmail.com> wrote in message news:1175119186.275874.78300@e65g2000hsc.googlegroups.com... > > Thanks for sharing the schematics! > > Hmm...the TDO and voltage sense line are the exactly the same as > orginally posted by Xilinix. For the other JTAG lines (TMS, TCK, TDI), > two schmitt-triggers and a buffer were used to increase noise > immunity. Thats a little bit too many components for my taste, but > seems to be reliable. Seems to be reliable as in... you've already tried it and seen your troubles go away? Your problem may not be on the Schmidt trigger side of your buffers but in the interface between the PC and the programmer chips. Have you tried your existing programmer on a different PC to see if the behavior is identical or vastly different? You could modify the Parallel-III style design with comparators and a low-voltage DC-DC boost converter with fixed 5V output to power the LPT-compatible circuit with a variable logic level I/O to get closer to Parallel-IV performance with a Parallel-III interface.Article: 117348
jidan1@hotmail.com schrieb: > Since this problem applies to more than one board, I assume the > problem must lay on the programmer itself. My explanation is that > maybe the buffer IC's get hot or something...I really don't know. > I want to know if there is anyone who has had problems with this > programmer cable. As I posted before, there are many issues with parallel cable 3, especially in conjunction with old versions of impact. (The old software versions simultaneously turn of the output enable and change the data output value resulting in a race condition) The main issue is, that the parallel port has TTL logic levels that only have a guaranteed V_OH of 2V. But a 5V powered 74HC125 has a threshold voltage of 2.5V which might never be reached. A 3.3V powered 75HC125 still has a threshold of 1.65V. In that range the slope of a parallel port output can be very slow, but the 74HC is quite fast. As a result noise on the parallel port will amplify to many clock edges to TCK. You can solder 2k resistors between each buffers input and output pin. (0402 SMT fits perfectly) This creates a schmitt trigger with a large hysteresis which helps a lot. For building your own cable there are CMOS families that have thresholds of 1/3 VCC instead of 1/2 VCC. A 50mV hysteresis is not enough, so you need the positive feedback from output to input in all cases. Kolja SulimmaArticle: 117349
Thank you to both Andreas and Paul. After reading your feedback, can I make this conclusion "Spartan FPGA has it's own clock which can fit most design".
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