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
Nathan Bialke wrote: > An asynchronous FIFO is probably the easiest way to do this. > Otherwise, there needs to be some set phase relationship between > fastClock and slowClock. I've tried the FIFO megafunction from Altera and it still didn't worked. The solution was to specify the speed of the slow clock in "Classic Timing Analyzer Setting" with "Individual Clocks". Now the AES3 sampling works without problems. If someone is interested: If you have a cheap AES3 clock recovery chip, like Cirrus or AKM produces it, instead of an expensive and more difficult to use VCXO, like described in the Altera appnote for AES3 decoding and encoding, then 5 clocks per AES unit most of the time is stable for sampling rates from 48 kHz to 192 kHz and 6 clocks per AES unit is perfect (with fixed sampling position after edge detection, instead of trying to calculate it at runtime, like described in the appnote). -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 140826
On May 26, 1:10=A0pm, halong <cco...@netscape.net> wrote: > On May 26, 11:00=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > On May 25, 12:47=A0am, yuchi...@gmail.com wrote: > > > Hexagon is possible, but it would generate more trouble for bus > > interconnections and it would generate waste materials along chip > > boundaries. > > > For more information, Xilinx patent: 7274214, "Efficient tile layout > > for a programmable logic device.pdf"http://www.google.com/patents?id=3D= dGeEAAAAEBAJ&dq=3Dpatent:7274214&as_dr... > > > I have carefully and thoroughly read the patent, but with purposes > > different from yours. It is very interesting and instructive. > > > Weng- Hide quoted text - > > > - Show quoted text - > > Spherical would be ideal You mean like Ball Semiconductor tried? RickArticle: 140827
Hi, just a quick idea. Have you used the right ucf file for your board? Without the proper connections between port signals and FPGA Pins your design won't work as intended. Have a nice synthesis EilertArticle: 140828
Mark <mark@cacurry.net> writes: > Ok neat. But why not just code the algorithm in straight verilog or > VHDL, instead of C generates verilog? The C generated verilog code > is unmanageable. I think this historically from the time when synthesis tools did not handle loops very well. It was very easy to do the expansion symbolically in a language like Common Lisp and generate HDL code. I've done this many times in the past and I disagree that the generated code is unmanageable. You simply stick it in a module and instantiate it. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 140829
Andreas Ehliar <ehliar-nospam@isy.liu.se> writes: > It is straight forward in Verilog as well. This is taken from an Ethernet > CRC32 module I wrote a long time ago: <snipped code> But that's not any poly at any length... Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 140830
Andreas Ehliar wrote: > On 2009-05-21, Mike Treseler <mtreseler@gmail.com> wrote: >> I agree, but not everyone is a language wonk. >> This is straightforward in vhdl, and has been >> covered repeatedly in the vhdl newsgroup. >> If you have done it in verilog, >> let's see the code. > > It is straight forward in Verilog as well. I agree. But consider what many Verilog designers have learned: * Think Hardware. * Don't mix blocking and non-blocking assignments. If I "think hardware" on an example such as yours, I easily get confused. To find such an elegant solution, I need to understand what HDLs and synthesis tools can do. Likewise, if I can't mix blocking and non-blocking assignments in a clocked always block, I can't write code like yours. In summary, unless Verilog RTL designers are prepared to discard what they are learning from all kinds of papers and trainers, they won't come up with such elegant solutions. No matter how straightforward we might find them. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.comArticle: 140831
Hello, I have a SoC and I will be able to Synthesize and implement it in the FPGA ( Spartan 3). Know, I want to send a sequence of bytes to the FPGA (Spartan 3) for test a Soc that I have implement in this fpga, but I don=92t know if there is a way to send from ISE Xilinx to the FPGA. Best regards lolitaArticle: 140832
On May 27, 11:18=A0am, lolita.tang...@gmail.com wrote: > Hello, > I have a SoC and I will be able to Synthesize and implement it in the > FPGA ( Spartan 3). > Know, I want to send a sequence of bytes to the FPGA (Spartan 3) for > test a Soc that I have implement in this fpga, but I don=92t know if > there is a way to send from ISE Xilinx to the FPGA. > Best regards > lolita try UPS they can send things AnttiArticle: 140833
halong wrote: > > Spherical would be ideal I disagree. I think toroidal is the optimum topology. Syms.Article: 140834
"Symon" <symon_brewer@hotmail.com> writes: > I disagree. I think toroidal is the optimum topology. Torodial is/was already done (if I remember right it was no FPGA, but one of Raytheone many core/massiv parallel units). Its relativly easy doable. You could also do it with a island style FPGA with slightly different routing, by interleaving: ------- ----- ----- | \/ \/ \ x---x x x x x x--x | /\ /\ | ------- ---- ------ (I am no good ASCI artist, but I hope the idea is clear (x island, rest routing, same approach for vertical, as this is only horizontaly)) FlorianArticle: 140835
<lolita.tangier@gmail.com> wrote in message news:3f5d6f0e-d7b4-40a2-a21b-69ec0c4478cb@r34g2000vbi.googlegroups.com... >Hello, >I have a SoC and I will be able to Synthesize and implement it in the >FPGA ( Spartan 3). >Know, I want to send a sequence of bytes to the FPGA (Spartan 3) for >test a Soc that I have implement in this fpga, but I don’t know if >there is a way to send from ISE Xilinx to the FPGA. >Best regards >lolita If you don't need speed look into using a good old UART. You can get some low-cost USB-2-Serial cables from eBay. Hans www.ht-lab.comArticle: 140836
Hello, I'm running a back-annotated simulation for which I need to know the encoding scheme for my signal. XST reports, "Found 4-bit register for signal <to_bus.request> where to_bus.request is of type (read_36,read_72,read_line,read_device,write_36,write_72,write_line, write_device,nothing,return_36,return_72,return_line,return_device, return_error,interrupt,UNDEF). Is there any way I can find out the encoding scheme for this to_bus.request signal? Thanks, ShanteshArticle: 140837
I don=92t know what UPS isArticle: 140838
lolita.tangier@gmail.com wrote: > I don’t know what UPS is Uninterruptible power supply.Article: 140839
shantesh wrote: > Hello, > > I'm running a back-annotated simulation > Why?Article: 140840
On 16 mei, 22:52, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > "gert1999" <ggd...@gmail.com> wrote in message > > news:af6b611f-0775-41ad-a664-ab6605364e88@o14g2000vbo.googlegroups.com... > On 16 mei, 19:08, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > > > > > "gert1999" <ggd...@gmail.com> wrote in message > > >news:95580829-2b4b-4981-acb5-9489958899bd@v4g2000vba.googlegroups.com... > > I've added some files on the same link > > First you got the reset line correct: it should be driven low instead > > of high (if reset=3D'0') > > Second I added the common driving kathode pins. In the manual they > > indicate they should all be driven low if not multiplexing. I've done > > so, this could also be derived from the schematic as the are pnp > > transistors. However I can't find any code in the handbook example: > > how do they drive them low if there is no code written ? Setting > > attributes might be the key ?? > > . > > A new version of the source is the file teller_update1.txt > > I placed screenshots of pinmapping, low level simulation of the > > counter, and top level simulation of the whole design > > > As one can see: the counter counts, but the LEDs are not being > > driven ?? They just stay low resulting in adeadboard > > What exactly do you mean by pull down atributes ? I only specified > > clock_ext DATA_GATE as they did so in the manual > > > =3D=3D=3D=3D=3D=3D=3D=3D > > You're now looking in the right places, and asking the right questions. > > The > > next step is to answer them yourself. ;) > > > Pullup and pulldown apply more to reading switches; don't let me confus= e > > you > > with my confusion. Data-gate is related to power save modes. Try disabl= ing > > it removing the attribute, or make sure its driven correctly. Try drivi= ng > > a > > constant '0' on the common cathode. Failing that, physically tie it to > > ground on theboard. Try probing with a meter and look for voltages you > > would expect. The LED pins should read somewhat less than half the high > > state voltage. Check that the display cathode is grounded, not just > > floating. Check that the data-gate pin reads whatever means not power > > save. > > > Good luck. > > =3D=3D=3D=3D > Thank's a lot for helping. =A0 I know about pullup and pulldown in > simpel logic (active / passive pull up and that kind of things) > I have been trying to answer the questions for several days and > decided to ask help :-) > > I'll see what to do with it > There are so many questions and Xilinx manuals are not very helpfull > (they make it look so simple .. =A0) > > If it ever works I wil leave a mesage here (if the article will still > be avaiilable in the newsgroup :-) ) > > =3D=3D=3D=3D=3D=3D=3D > Double check that reset pin. The testbench likely just needed a simple > stimulus to take it out of reset, something like rst <=3D '0', while the = code > was actually fine. Read the schematic and be sure you have the right > pullup/down sense on that pin. Same with data-gate. Probe the logic level= s > with a meter. If you have an I/O header available, route the signals to t= he > header to make probing easier and somewhat safer. > > It is a lot to swallow all at once, but it sounds like you have a fair gr= asp > of the tools. At this point, it's less a matter of the Xilinx docs than i= t > is assumptions about theboard. Take out the reset at the top level and se= t > it to constant '1' in your code. Check the pin locations in the ucf. Take > out the data-gate until you have it working. I didn't see an led_enable p= in > at the top level entity. Check the schematic and see that it is wired to > ground rather than a pin. I solved the problem ! All I had to do is adding the following timing constraints clock period 40 ns offset before clock 10 ns offset after clock 10 ns It just works and had nothing but absolutely nothing to do with the code I wonder why the manual did not mention anything about this ? I hope this might be usefull for someone else, that's the reason I add this message on this thread Thanks a lot for help GertArticle: 140841
On May 26, 7:22=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > On May 26, 3:21=A0pm, Andy <jonesa...@comcast.net> wrote: > > > > > > > This example shows one way to handle outputs, but inserts a one clock > > delay on the output. > > > State2 : process(CLK) > > begin > > =A0 =A0if rising_edge(CLK) then > > =A0 =A0 =A0 turn_on <=3D '0'; > > =A0 =A0 =A0 if SINI =3D '1' then > > =A0 =A0 =A0 =A0 State2 <=3D Idle_S; > > =A0 =A0 =A0 else > > =A0 =A0 =A0 =A0 case State2 is > > =A0 =A0 =A0 =A0 when Idle_S =3D> > > =A0 =A0 =A0 =A0 =A0 if A1 =3D '1' then > > =A0 =A0 =A0 =A0 =A0 =A0 turn_on <=3D '1'; > > =A0 =A0 =A0 =A0 =A0 =A0 State2 <=3D X_S; > > =A0 =A0 =A0 =A0 =A0 end if; > > =A0 =A0 =A0 =A0 when X_S =3D> > > =A0 =A0 =A0 =A0 =A0 if A2 =3D '1' then > > =A0 =A0 =A0 =A0 =A0 =A0 State2 <=3D Idle_S; > > =A0 =A0 =A0 =A0 =A0 end if; > > =A0 =A0 =A0 =A0 end case; > > =A0 =A0 =A0 end if; -- sini > > =A0 =A0end if; -- clk > > end process; > > > If you want to avoid the delay, just assert the output when you > > transition into the states in which you want it on. I think it was > > Jonathan Bromley that demonstrated a method, using variables, to > > describe state machine outputs more easily in a single clocked > > process. > > > It's not that hard to do, and you don't get latches, ever! > > > If you really prefer dual-process state machines, there are proven, > > easy ways to avoid latches in them (like default "State <=3D State_NS" > > assignments). Quite frankly, I'd prefer the synthesis vendors work on > > other optimizations that are more important to quality of results, > > than avoiding inferring latches from poorly written RTL code. > > > Andy > > Hi Andy, > "If you really prefer dual-process state machines, there are proven, > easy ways to avoid latches in them (like default "State <=3D State_NS" > assignments)." > > Very good suggestions !!! I will follow it in all my designs starting > today. Actually I give a default value at head of each of important > states, not for full state machine. > > But your method of one process with turn-on signal delayed by 1 clock > is not acceptable to me. > > That is the fatal fault of one process and the main reason for me to > use dual-process method. > > One may like vegetables and others may like beef and pork. There is no > need to compare between two methods, I know, it is a long crusade in > VHDL industry. > > Weng- Hide quoted text - > > - Show quoted text - I agree there are multiple valid ways to design a state machine, each with their trade-offs (e.g. latches vs output timing issues). I prefer to deal with the former, and gain the other benefits of single, clocked process descriptions, others (yourself included) may not. Single, clocked process descriptions also allow the flexibility of using VHDL variables for specifying both combinatorial and registered behavior in a compact, straight-forward manner (the circuit behaves just like the code sequential code reads). One of the primary benefits of assigning default values in combinatorial processes, right up front, for every signal driven by that process, is that this is the most easily remembered/verified/ reviewed place to do it. You can default the state variable to the current registered value, but choose to default outputs either to the "off" state or to the current registered value, depending on how you want to describe the output in the state machine. For example, do you want to describe when the output changes, or do you just want to describe when it should be on? Judicious choice of the default value can greatly simplify the coding of the state machine and outputs themselves (i.e. state machines only need to describe transitions to other states, letting the default assignment take care of waiting in the same state). If you try to make decisions about this signal or that signal being "important" enough to include or exclude a default, you are more likely to forget to properly handle something, and get a latch, and it is much harder to verify/review that each signal is properly handled. AndyArticle: 140842
On May 27, 7:28=A0am, "shantesh" <shantes...@gmail.com> wrote: > Hello, > > I'm running a back-annotated simulation for which I need to know the > encoding scheme for my signal. > > XST reports, "Found 4-bit register for signal <to_bus.request> > > where to_bus.request is of type > (read_36,read_72,read_line,read_device,write_36,write_72,write_line, =A0 = =A0 =A0 > write_device,nothing,return_36,return_72,return_line,return_device, > return_error,interrupt,UNDEF). > > Is there any way I can find out the encoding scheme for this > to_bus.request signal? > > Thanks, > Shantesh It should be in the synthesis report. Beware, the encoding is subject to change with other changes to the design. If you just need to know what state you're in on a waveform viewer, that's fine, but if you need your testbench to interact with it, you should create a decoded output that your test bench can access. AndyArticle: 140843
On May 27, 8:56=A0am, "Symon" <symon_bre...@hotmail.com> wrote: > shantesh wrote: > > Hello, > > > I'm running a back-annotated simulation > > Why? There are several valid reasons to run a back-annotated simulation for FPGA designs. The most common is to verify that multi-cycle path and false path constraints are valid. I prefer to run as little back- annotated simulation as possible (none if I don't have any MCP/FP constraints), because I can verify a lot more corner cases in the same amount of time by simulating the RTL instead. Back-annotated simulations should not be used to verify timing, but instead used to verify the constraints that relax the static timing analysis that verifies the timing. AndyArticle: 140844
On May 27, 10:32=A0am, Andy <jonesa...@comcast.net> wrote: > On May 27, 7:28=A0am, "shantesh" <shantes...@gmail.com> wrote: > > > > > Hello, > > > I'm running a back-annotated simulation for which I need to know the > > encoding scheme for my signal. > > > XST reports, "Found 4-bit register for signal <to_bus.request> > > > where to_bus.request is of type > > (read_36,read_72,read_line,read_device,write_36,write_72,write_line, = =A0 =A0 =A0 > > write_device,nothing,return_36,return_72,return_line,return_device, > > return_error,interrupt,UNDEF). > > > Is there any way I can find out the encoding scheme for this > > to_bus.request signal? > > > Thanks, > > Shantesh > > It should be in the synthesis report. Beware, the encoding is subject > to change with other changes to the design. If you just need to know > what state you're in on a waveform viewer, that's fine, but if you > need your testbench to interact with it, you should create a decoded > output that your test bench can access. > > Andy The user can specify the encoding of a user defined (enumerated) type. Just because of these sorts of issues, I typically define the encoding of my enumerated types. If I really want the tools to try to optimize the encoding, I can always do that last after I am sure the design is working. If you really need to do it this way, you can always use the attribute 'value to find the values of the enumerated signals. I believe this maps to the encoding, but I won't swear to that. You can brute force figure it out in simulation. This signal sounds like a state machine, so it should start up in a known initial state, or at least be preset to a value with one of the control signals at the beginning of simulation. Then you can watch the state transitions and inputs and see what hardware values are being used. These are not pretty solutions, but I didn't create the problem. I prefer to side step issues like these and tell the tool what encoding to use. RickArticle: 140845
Start with something simple, e.g. a flashing LED. /MikhailArticle: 140846
On May 27, 10:09=A0am, gert1999 <ggd...@gmail.com> wrote: > On 16 mei, 22:52, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > > > > > "gert1999" <ggd...@gmail.com> wrote in message > > >news:af6b611f-0775-41ad-a664-ab6605364e88@o14g2000vbo.googlegroups.com..= . > > On 16 mei, 19:08, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > > > > "gert1999" <ggd...@gmail.com> wrote in message > > > >news:95580829-2b4b-4981-acb5-9489958899bd@v4g2000vba.googlegroups.com.= .. > > > I've added some files on the same link > > > First you got the reset line correct: it should be driven low instead > > > of high (if reset=3D'0') > > > Second I added the common driving kathode pins. In the manual they > > > indicate they should all be driven low if not multiplexing. I've done > > > so, this could also be derived from the schematic as the are pnp > > > transistors. However I can't find any code in the handbook example: > > > how do they drive them low if there is no code written ? Setting > > > attributes might be the key ?? > > > . > > > A new version of the source is the file teller_update1.txt > > > I placed screenshots of pinmapping, low level simulation of the > > > counter, and top level simulation of the whole design > > > > As one can see: the counter counts, but the LEDs are not being > > > driven ?? They just stay low resulting in adeadboard > > > What exactly do you mean by pull down atributes ? I only specified > > > clock_ext DATA_GATE as they did so in the manual > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > You're now looking in the right places, and asking the right question= s. > > > The > > > next step is to answer them yourself. ;) > > > > Pullup and pulldown apply more to reading switches; don't let me conf= use > > > you > > > with my confusion. Data-gate is related to power save modes. Try disa= bling > > > it removing the attribute, or make sure its driven correctly. Try dri= ving > > > a > > > constant '0' on the common cathode. Failing that, physically tie it t= o > > > ground on theboard. Try probing with a meter and look for voltages yo= u > > > would expect. The LED pins should read somewhat less than half the hi= gh > > > state voltage. Check that the display cathode is grounded, not just > > > floating. Check that the data-gate pin reads whatever means not power > > > save. > > > > Good luck. > > > =3D=3D=3D=3D > > Thank's a lot for helping. =A0 I know about pullup and pulldown in > > simpel logic (active / passive pull up and that kind of things) > > I have been trying to answer the questions for several days and > > decided to ask help :-) > > > I'll see what to do with it > > There are so many questions and Xilinx manuals are not very helpfull > > (they make it look so simple .. =A0) > > > If it ever works I wil leave a mesage here (if the article will still > > be avaiilable in the newsgroup :-) ) > > > =3D=3D=3D=3D=3D=3D=3D > > Double check that reset pin. The testbench likely just needed a simple > > stimulus to take it out of reset, something like rst <=3D '0', while th= e code > > was actually fine. Read the schematic and be sure you have the right > > pullup/down sense on that pin. Same with data-gate. Probe the logic lev= els > > with a meter. If you have an I/O header available, route the signals to= the > > header to make probing easier and somewhat safer. > > > It is a lot to swallow all at once, but it sounds like you have a fair = grasp > > of the tools. At this point, it's less a matter of the Xilinx docs than= it > > is assumptions about theboard. Take out the reset at the top level and = set > > it to constant '1' in your code. Check the pin locations in the ucf. Ta= ke > > out the data-gate until you have it working. I didn't see an led_enable= pin > > at the top level entity. Check the schematic and see that it is wired t= o > > ground rather than a pin. > > I solved the problem ! > All I had to do is adding the following timing constraints > > clock period 40 ns > offset before clock 10 ns > offset after clock 10 ns > > It just works and had nothing but absolutely nothing to do with the > code > I wonder why the manual did not mention anything about this ? > > I hope this might be usefull for someone else, that's the reason I add > this message on this thread > > Thanks a lot for help > > Gert That is actually an odd solution to a problem that shows in simulation. Did you find other changes that were needed to the code. I looked at the code and I don't see a reason for the led outputs to all be zero if the decade counter is counting. It appears that you verified the decade counter and the top level led output separately. Is there a reason why you didn't look at the decade counter output in the top level simulation? My guess is that there is something else wrong. Until you can simulate your code I would not trust that it is working correctly. RickArticle: 140847
on a spartan 3e, the DCM speaks to havein a high-resolution phase shifting function, but it goes on and says the DCM has a wide frequency range of 5MHz to 300MHz. How can I get my 2MHz signal phase locked? The idea is this, I have a 2MHz signal coming in on a pin, and I want to mimic that signal on an internal std_logic pin with the idea that if the 2MHz signal on the incoming pin is ever lost, the internal std_logic pin continues the original timing as if nothing has happened. Any suggestions?Article: 140848
On May 27, 4:55=A0pm, "Symon" <symon_bre...@hotmail.com> wrote: > lolita.tang...@gmail.com wrote: > > I don=92t know what UPS is > > Uninterruptible power supply. United Parcel Service, maybe also try DHL or Fedex if UPS can not send the bytes as fast as needed AnttiArticle: 140849
79MHz (slow corner C5), 5 cycles per instruction, 610 LEs (MAX II), SPI hardware sequenced boot loader for command 03 read (16 bit address) EEPROM. 1/5 clock DMA address presentation (read only). Full interleaved decode pipeline for speed. A few things left to do generic wide fix for SPI SPI software interface Not much else. cheers jacko
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