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
I'm starting new FPGA design. In some previous projects I've used schematic entry, but for this one I would like to dive into HDL. My dilemma is - VERILOG or VHDL. Design is Xilinx Spartan II based. What are advantages/disadvantages for both of them? Which one to pick up? Thank you for all suggestions. DamirArticle: 27901
I am using XCS40 chips in my design. I have found the following problem: 1.The /INIT and HDC keeps high, the /LDC keeps low during configuration. 2.The output 40 bits from DOUT pin are correct. 3.The input stream to DIN is also correct. 4.After the postamble 7FFF has sent to DIN pin, the Done goes high. but it returns to low after 7 CCLK period. 5.I have checked the .bit file, the content(preamble and postamble) of the file is correct, the bit stream length is also correct. The /INIT and DONE pin are pulled up through a 4.7K resistor, and the DONE pin is not pulled down externally. The fill bits before preamble is 8 1s. I don't know what to do to solve this problem. Would you please give me some valuable advices?Article: 27902
by the way, I am using Foundation 1.5iArticle: 27903
Does anyone have schematic or VHDL block for decoding output of incremental (quadrature) encoder (including pulse up/down) counter? Regards, DamirArticle: 27904
I think you've answered your own question. The amount of processing
required WOULD take that time.
One question - Why do you chain SO MANY devices together?
What with very large devices available nowadays I'd have thought that
even very complex designs would fit into just a few.
--
____________________________________________
/ /|
/ H A R V E Y T W Y M A N / |
/ ----------------------------------------- / \|
===/ Department of Electronics, / \/======
===/ University of Kent. / \/======
===/ Canterbury. U.K. / \/======
===/ ----------------------------------------- / \/======
===/ ABOUT ME: http://www.Twyman.org.uk/CV.htm / \/======
===/ ----------------------------------------- / \/======
===/ EMAIL ME: H.E.Twyman@ukc.ac.uk / \/======
===/___________________________________________/ \/======
====| |\/======
=====|___________________________________________|/======
In article <ys2oitornf3s.fsf@pcep-jamie.cern.ch>,
Jamie Lokier <spamfilter.dec2000@tantalophile.demon.co.uk> wrote:
> harveytwyman writes:
> > We use the Altera MaxPlus II Development Tool in my department.
> > It has the JTAG facility for configuring individual devices or
multiple
> > devices in cascade. They can be different types of FPGA or even
> > Configuration storage Devices like the EPC2.
>
> It works pretty well.
>
> But have you ever tried building a JTAG programming file for 32
devices
> on a 35 device chain with Maxplus2? On our Suns it took about 40
> minutes to make the programming file. The initial Place & Route step
> took about 3 minutes.
>
> -- Jamie
>
Sent via Deja.com
http://www.deja.com/
Article: 27905In article <91a50h$f3on$1@as121.tel.hr>, "Damir Danijel Zagar" <damir.zagar@tipro.hr> wrote: > Does anyone have schematic or VHDL block for decoding > output of incremental (quadrature) encoder (including pulse > up/down) counter? Regards, > > Damir > > I can not share my code with you, since it belongs to my company. It is however easy to design, look at the FSM below. For driving the FSM you need a clock whose frequency is at least 10 x the maximum encoder frequency. Additionally I would recommend not to feed the outputs of the quadrature encoder directly to the decoder, but to add a digital low pass filter. I have done this in a very simple way, only when a signal is stable for 4 clock cycles, the output switches too. If you feed the encoder signals directly to the FSM you will have problems with metastability. -- <--- DOWN +---------+ -- UP ----> -- | CHA = 0 | -- ------------->| CHB = 0 |---------------+ -- | | | | -- | | state 0 | | -- | +---------+ | -- | /\ \/ -- +---------+ | +---------+ -- | CHA = 0 | Zero | CHA = 1 | -- | CHB = 1 | | CHB = 0 | -- | | | | -- | state 3 | | state 1 | -- +---------+ +---------+ -- /\ | -- | | -- | +---------+ | -- | | CHA = 1 | | -- +-------------| CHB = 1 |<--------------+ -- | | -- | state 2 | -- +---------+ Hope this helps -- Klaus Falser Durst Phototechnik AG I-39042 Brixen Sent via Deja.com http://www.deja.com/Article: 27906
Thank you... I've figured out how to do it... Damir "Klaus Falser" <kfalser@durst.it> wrote in message news:91ahc8$lf7$1@nnrp1.deja.com... > In article <91a50h$f3on$1@as121.tel.hr>, > "Damir Danijel Zagar" <damir.zagar@tipro.hr> wrote: > > Does anyone have schematic or VHDL block for decoding > > output of incremental (quadrature) encoder (including pulse > > up/down) counter? Regards, > > > > Damir > > > > > I can not share my code with you, since it belongs to > my company. It is however easy to design, look at > the FSM below. > For driving the FSM you need a clock whose frequency > is at least 10 x the maximum encoder frequency. > Additionally I would recommend not to feed the > outputs of the quadrature encoder directly to the decoder, > but to add a digital low pass filter. > I have done this in a very simple way, > only when a signal is stable for 4 clock cycles, > the output switches too. > If you feed the encoder signals directly to the FSM > you will have problems with metastability. > > > -- <--- DOWN +---------+ -- UP ----> > -- | CHA = 0 | > -- ------------->| CHB = 0 |---------------+ > -- | | | | > -- | | state 0 | | > -- | +---------+ | > -- | /\ \/ > -- +---------+ | +---------+ > -- | CHA = 0 | Zero | CHA = 1 | > -- | CHB = 1 | | CHB = 0 | > -- | | | | > -- | state 3 | | state 1 | > -- +---------+ +---------+ > -- /\ | > -- | | > -- | +---------+ | > -- | | CHA = 1 | | > -- +-------------| CHB = 1 |<--------------+ > -- | | > -- | state 2 | > -- +---------+ > > Hope this helps > -- > Klaus Falser > Durst Phototechnik AG > I-39042 Brixen > > > Sent via Deja.com > http://www.deja.com/Article: 27907
Hi, Strange behaviour. Have you checked that the /PROG pin is not pulled down for some reason, and kept low? /Thomas Jerry wrote: > > I am using XCS40 chips in my design. I have found the following > problem: > > 1.The /INIT and HDC keeps high, the /LDC keeps low during > configuration. > 2.The output 40 bits from DOUT pin are correct. > 3.The input stream to DIN is also correct. > 4.After the postamble 7FFF has sent to DIN pin, the Done goes high. > but it returns to low after 7 CCLK period. > 5.I have checked the .bit file, the content(preamble and postamble) > of the file is correct, the bit stream length is also correct. > > The /INIT and DONE pin are pulled up through a 4.7K resistor, and > the DONE pin is not pulled down externally. The fill bits before > preamble is 8 1s. > > I don't know what to do to solve this problem. Would you please > give me some valuable advices?Article: 27908
When we asked this same question about 2 years ago, and our Xilinx FAE told us to go with Verilog. So all of my experience since then has been with verilog. My guess is that eveyone would respond that whatever hdl they use is best, and like them, I cannot give a very objective opinion. I can supply a couple of observations. One is that Verilog is much more dense - If you look at a Xilinx app note that supplies example code in VHDL and Verilog, it always seems that the VHDL is 4x as long. Not that this is necessarily a bad thing... You might want to take a look at one of these and see which you find more readable. Also, a big advantage to us has been that all of our clients use Verilog - in fact I have not yet come in contact with anyone who uses VHDL, but again, this is just me. I do know that much of the world's ASIC design is done in verilog. I once heard that the difference is like the programming languages C and ADA. They both can get the job done. C is quicker to code, but easier to shoot yourself in the foot. ADA has a lot of conventions to prevent this (resulting in longer listings). Your Xilinx FAE might be a good person to ask. Jason Daughenbaugh http://www.aedinc.netArticle: 27909
I know that the HDL implementation is important for protability reasons, are you tied to using Exemplar... have you tried your design with XST? Colm. Marcel Melters wrote: > Hi Colm, > > you are absolutely correct, I'm trying to INFER dual port block RAM. > This should result in a more "portable" code, which does not depend on > the target device (Virtex 50E at the moment). > There is a mention in the LeonardoSpectrum Synthesis and Technology > Manual, v2000.1, of a VHDL example of a Block RAM. > Unfortunately, this example only deals with a Single-port RAM. > Every modification I tried to convert this to a dual-port RAM failed so far. > > If all else fails, I will have to instantiate, using coregen, as you > suggested. > Thank you for your suggestions, > > Marcel. > > Colm Clancy wrote: > > > Hi Marcel, > > > > Sounds like you are trying to infer a dual port block ram rather than > > using an instantiated component. > > > > Can Examplar Leonardo infer DPBrams i.e. are they supported..... If so > > does Exemplar require that your HDL description of the ram follow a > > specific template in order to infer this component. > > > > Alternativly: If DPBrams are not supported ... > > > > you can instantiate the actual component(s) directly from the unsims > > library as suggested by Vikram... > > Use coregen to generate the DPBRAM you need and instantiate that in your > > code > > > > Hope this helps > > > > Colm. > > > ============================================================= > > Ing. Marcel Melters Philips Medical Systems > Hardware engineer Veenpluis 6 > MR-backend room QR-2155 5684 PC Best > mailto: marcel.melters@philips.com P.O. box 10000 > phone +31 40 27 63266 5680 DA Best > fax +31 40 27 63771 The Netherlands > =============================================================== > ... deadlines? I like deadlines ... > I like the "whoosh" sound they make when they rush past ... > Douglas Adams, author of T.H.H.G.T.T.G.Article: 27910
Hello Colm,
Thank you for your response, but to answer your question:
Yes, I am completely tied to using Exemplar Leonardo (v2000)
There are two big reasons for this :
- Since our development toolchain needs to be maintained throughout the service life
of the equipment we design with it, which is about 17 years ....
- Another reason for wanting to limit the number of tools we use, is the fact that
we need to FDA-certify our development tools, which is (as far as I understand) a
costly and time-consuming process...
So I'm afraid I am "stuck" with using Exemplar Leonardo...
... so any hints on how to infer a synchronous dual-ported RAM from Leonardo are
still much appreciated...
thank you,
Marcel
Colm Clancy wrote:
> I know that the HDL implementation is important for protability reasons, are you
> tied to using Exemplar... have you tried your design with XST?
>
> Colm.
===============================================================
Ing. Marcel Melters Philips Medical Systems
Hardware engineer Veenpluis 6
MR-backend room QR-2155 5684 PC Best
mailto: marcel.melters@philips.com P.O. box 10000
phone +31 40 27 63266 5680 DA Best
fax +31 40 27 63771 The Netherlands
===============================================================
... deadlines? I like deadlines ...
I like the "whoosh" sound they make when they rush past ...
Douglas Adams, author of T.H.H.G.T.T.G.
Article: 27911How about XESS student kit? Any good/bad experience with this kit? BassemArticle: 27912
Hi It's a difficult decision. I suggest you to look around and try to find out which language is the most used among your colleagues. In Europe it's easier to find VHDL users than in the USA. BTW, have you heard of Handel-C? Eduardo. "Jason A. Daughenbaugh" wrote: > > When we asked this same question about 2 years ago, and our Xilinx FAE told us to go with Verilog. So all of my experience since then has been with verilog. My guess is that eveyone would respond that whatever hdl they use is best, and like them, I cannot give a very objective opinion. I can supply a couple of observations. One is that Verilog is much more dense - If you look at a Xilinx app note that supplies example code in VHDL and Verilog, it always seems that the VHDL is 4x as long. Not that this is necessarily a bad thing... You might want to take a look at one of these and see which you find more readable. > Also, a big advantage to us has been that all of our clients use Verilog - in fact I have not yet come in contact with anyone who uses VHDL, but again, this is just me. I do know that much of the world's ASIC design is done in verilog. > I once heard that the difference is like the programming languages C and ADA. They both can get the job done. C is quicker to code, but easier to shoot yourself in the foot. ADA has a lot of conventions to prevent this (resulting in longer listings). > > Your Xilinx FAE might be a good person to ask. > > Jason Daughenbaugh > http://www.aedinc.netArticle: 27913
"Dave Nadler" <drn@nadler.com> wrote in message news:3A352101.289B4FDE@nadler.com... > This is a newbie question, but I'd appreciate help... > > I have an FPGA attached to a uC bus. The uC bus is async w/respect > to the FPGA. The bus interface is "clocked" by the "WR" strobe > (Intel-style bus), so I latch the data for the FPGA based on the > WR transition (subject to CS etc), and also I set a latch that > indicates "data ready". > > Now, I need the FPGA state machine to "notice" that there's data > sitting and waiting to be processed, in the latch, in a glitch-free > manner. I want to put a second latch triggered on the FPGA clock > after the "data has arrived" latch, to ensure I've got glitch-free > access to the incoming data. After I've processed the incoming > data, I need to clear the (sync and async) "data ready" latches. > > Anybody got some hints, or better yet an example, of a good > way to handle this in VHDL, which is synthesizable without > "multiple-source" errors ? > Or, anybody got advice on what further textbooks I should > read ? > > Thanks in advance for your help, > Best Regards, Dave I'm afraid I can't remember my sources, but here's what I've done in the past. Use the WR signal to clock a flip-flop whose output is inverted going back into the input. When the WR signal transitions from low to high, the flip-flop output will toggle. Take this new signal and feed it to three flip-flops chained together serially, all clocked synchronously to your internal logic. When the value at the second and third outputs does not match, this will indicate that a new piece of data is available. This assumes that your internal logic is much faster than the incoming data rate. If this is not the case, then you will need to maintain a counter clocked by the WR counter. Running the output of the counter through two stages of flip-flops should be sufficient to ensure no metastability problems. You may want to try and get your hands on a document called "Metastable Response in 5-V Logic Circuits" written by Texas Instruments, document number SDYA006. It's a bit old now, but it shows you how to calculate the mean time between errors when using various levels of re-timing. Cheers, JamieArticle: 27914
"Martin Heimlicher" <heimlicher@scs.ch> wrote in message news:3a37e67f@news.datacomm.ch... > Dear all, > > This is a very basic and general FPGA question: > > How do I assure that an externally supplied reset signal connected to some > sort of GSR (global set/reset) net releases all registers simultaneously (in > the same clock cycle) and reliably (no metastability) ? > > Do I need to synchronize the external reset signal through one or two > registers before feeding it to the GSR net ? > > If yes, what do I do in the case of multiple clocks in a design ? Can I use > the GSR net only to reset registers clocked by one clock and using other > routing ressources to reset registers clocked by the other clocks ? > > If I am worrying to much about this issue: How do FPGAs circumvent these > problems ? > > Regards, > Martin Heimlicher, Supercomputing Systems AG, Switzerland Martin; Read the documentation for your FPGA and you should be able to find numbers for the global reset routing skew. If the skew is larger than your clock period, then you will potentially have registers coming out of reset two clock cycles before others. Depending on your design, this may or may not be a problem. In the case of Xilinx Virtex, they are no longer recommending the use of the global reset (startup block). Instead they use normal routing, which can be constrained to have skew less than your clock period. Otherwise, ensure your design can tolerate some registers being clocked 2-3 times more than others when coming out of reset. This usually just means making sure everything is reset to an in-active state. Cheers, JamieArticle: 27915
"Damir Danijel Zagar" <damir.zagar@tipro.hr> wrote in message news:91a2q0$f7va$1@as121.tel.hr... > I'm starting new FPGA design. In some previous projects I've used > schematic entry, but for this one I would like to dive into HDL. > My dilemma is - VERILOG or VHDL. Design is Xilinx Spartan II based. > What are advantages/disadvantages for both of them? Which one > to pick up? Thank you for all suggestions. > > Damir It would be easy to go on at length about the relative merits of each language, and start a massive debate. My belief is that if you're doing FPGA design as a profession, you should learn both Verilog and VHDL. Still, I recommend VHDL for beginners. As someone else pointed out, Verilog is easier to make mistakes in. For example, you can assign one signal to another, even if they aren't of the same width. VHDL considers this a mistake, and won't compile. Usually it come down to what the people you work with know. You probably wouldn't want to be the lone person using VHDL or Verilog in your outfit because you'd have no one to turn to with questions. Cheers, JamieArticle: 27916
I would look very carefully at the /PROG pin. Since DONE goes high, we know that you are doing everything else correctly. When /DONE goes low, what happens to LDC and HDC? Is there a pullup on the /DONE pin? Maybe once the chip goes live, one of the outputs (that was tristate during config) turns on, and is low, and is shorted to /PROG Maybe the chip goes live, and there is a problem with it drawing too much power (By design, or an output that is shorted to ground is driven high by the chip, or ....) and the VCC drops low enough that the FPGA decides that it needs to reconfig. Maybe when the chip goes active it generates enough noise (insufficient decoupling) that the source component for /PROG is triggering a reconfig. Let us know what it is, when you find it. Philip Freidin On Thu, 14 Dec 2000 01:34:01 -0800, Jerry <zhangwei@mail.cic.tsinghua.edu.cn> wrote: >I am using XCS40 chips in my design. I have found the following >problem: > >1.The /INIT and HDC keeps high, the /LDC keeps low during > configuration. >2.The output 40 bits from DOUT pin are correct. >3.The input stream to DIN is also correct. >4.After the postamble 7FFF has sent to DIN pin, the Done goes high. > but it returns to low after 7 CCLK period. >5.I have checked the .bit file, the content(preamble and postamble) > of the file is correct, the bit stream length is also correct. > >The /INIT and DONE pin are pulled up through a 4.7K resistor, and >the DONE pin is not pulled down externally. The fill bits before >preamble is 8 1s. > >I don't know what to do to solve this problem. Would you please >give me some valuable advices? Philip Freidin FliptronicsArticle: 27917
"Damir Danijel Zagar" <damir.zagar@tipro.hr> writes: >I'm starting new FPGA design. In some previous projects I've used >schematic entry, but for this one I would like to dive into HDL. >My dilemma is - VERILOG or VHDL. Design is Xilinx Spartan II based. >What are advantages/disadvantages for both of them? Which one >to pick up? Thank you for all suggestions. Oversimpifying, as usual, if you like coding in C you will probably like verilog better. If you don't like C, maybe Pascal, Fortran, or COBOL, then maybe VHDL. -- glenArticle: 27918
On Wed, 13 Dec 2000 22:13:37 +0100, "Martin Heimlicher" <heimlicher@scs.ch>
wrote:
>Dear all,
>
>This is a very basic and general FPGA question:
Basic, and general, and extremely important.
>How do I assure that an externally supplied reset signal connected to some
>sort of GSR (global set/reset) net releases all registers simultaneously (in
>the same clock cycle) and reliably (no metastability) ?
It's difficult, and dependent on your clock frequency. The core of the
problem is that while the GSR signal is useful, its routing resources
are not particularly fast, and Xilinx does not specify a skew parameter
for it, or a min delay. Consider the following:
case 1) GSR max delay is 20ns, (min delay is 0, guaranteed by reality)
and your clock period is 15nS
case 2) GSR max delay is 20ns, (min delay is 0, guaranteed by reality)
and your clock period is 150nS
Let us assume that we are only worried about the relationship between
the release of reset, and the next asserting edge of the clock.
Let us be pessimistic (which is the ONLY way to design robust systems)
and assume that when GSR is de-asserted, some FFs will see the release
at close to 0 nS later, and some will see it at the max delay (20 nS), and
most will see it at times between these two limits.
Also, let's assume the recovery time for a flipflop from reset being
de-asserted to clock edges being recognized is 3nS
For case 1, there are guaranteed to be problems, unless specific effort
is expended to deal with the situation.
For case 2, provided that GSR is released (at its source) at less than
(150-20-3 => 127) nS AFTER the clock's asserting edge,
everything will be ready for the next clock edge.
Unfortunatel, case 1 is the more common situation: GSR net delay is
greater than clock cycle time.
>Do I need to synchronize the external reset signal through one or two
>registers before feeding it to the GSR net ?
For Case 1, this will not help. For Case 2 this is sufficient.
For Case 1, what many of us recommend is this: In your design, add
extra logic such that if (when) various FFs have their reset released
in different clock cycles, the system still works. So lets look at the FFs
in your system. Some wil start toggling immediately when reset is
released, and others won't change until after a few clock cycles. For
example, in a counter, the LSB will change on the first rising edge,
but the rest of the FFs wont change. So only the LSB FF is in danger.
If I had two counters that are supposed to be in lock step, and the
reset release occurs at different times, and the clock edge occurs
between the two releases, one counter will be ahead by 1 count.
Here is a (the) recomended solution.
Identify all FFs that are the ones that can change state on the first
clock edge. If they dont change, no other FF can change. For these
FFs, add a synchronous reset signal, or tie their CE pins together.
If the CE is held low on just these FFs, or if the Sync Reset is asserted
(to just this subset of FFs), then no FF can change. Build a
statemachine that controlls this CE or sync-reset signal.
The SM is trivial. it is a shft register, with the D pin of the first FF
tied high. When the chip comes out of async reset, the SR will
go from 0000 to 0001 if the first FF has its reset released, and a
clock happens. After the second clock it is 0011 then 0111 and
finally 1111 . Note that if GSR is still reseting any of the FFs, the
last FF cant go high. Note that the first FF can go metastable. So
could the others if the previous bit is high, and reset de-asserts
just as the clock arrives.
Detect that all bits of the SR are '1', and synchronously use this to
enable the set of FFs that have the extra sync reset, or CE control.
How long should the shift register be?
N = (CEIL(max GSR delay / clock period)) + 1+ paranoid metastable FFs)
i.e. max GSR delay 25 nS , clock period is 10ns
Ceil( 25 / 10) + 1 + 2
3 + 1 + 2
6
So 6 FFs in the SR. (if you are more paranoid, add a few more, they are cheap.)
A 6 input AND looks at all the Q's and that signal goes to 1 more FF, and its
output is the system GO signal. The system actually starts up about 70 nS after
the GSR is released, well after the GSR has been de-asserted to all FFs.
Bonus: No need to externally sync the signal that is supplied as GSR.
>If yes, what do I do in the case of multiple clocks in a design ? Can I use
>the GSR net only to reset registers clocked by one clock and using other
>routing ressources to reset registers clocked by the other clocks ?
The GSR is prerouted to ALL FFs, and when it is asserted, ALL FFs will
be reset. Use multiple copies of my above described SR base system-GO
circuit, one for each clock domain, You may need to link them together
so that GO signals reach each domain at the right time.
>If I am worrying to much about this issue: How do FPGAs circumvent these
>problems ?
In the past, Xilinx acknowledged that this net is slow, but no further support.
In recent times, rather than explaining that this was a problem, and that there
are circuit based solutions (such as the one just described), Xilinx has instead
just recommended not to use the GSR net, thereby side stepping the issue,
and creating routing nightmares when general routing resources are now
used to reset potentially thousands of FFs. I have heard of designs that P&R
in 30 minutes with the GSR net, and take 7 hours with a non GSR net doing
the same task. Me, I prefer 30 minutes, and a 6 bit shift register.
>Regards,
> Martin Heimlicher, Supercomputing Systems AG, Switzerland
>
Philip Freidin
Fliptronics
Article: 27919usually This problem occurs when you give value to the same signal in different process Andy Peters n o a o [.] e d u> <"apeters <"@> wrote in message news:918lie$2cu8$1@noao.edu... > Tesisti DSPLab wrote: > > > > Hallo, > > > > we are implementing single-process applications > > and we find the following error: > > > > The net "clr" has more than one driver (FPGA-CHECK-5) > > > > Xilinx Help has not this entry in its database: is that > > possible? > > Yup. There's a lot of things that aren't in the database. > > > The portion of the VHDL file that gives this problem follows: > > It's not in the code you posted. The error message is quite explicit: > there's more than one driver for the net "clr" so you must look through > your code to find out what's actually driving clr. > > It might help to simulate your code first. > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u > > "It is better to be silent and thought a fool, > than to send an e-mail to the entire company > and remove all doubt."Article: 27920
I remarked a very strange metastable situation at my toilet flush. Pushing it through, it generates a waterpulse of about 2sec duration, then the water stops. Everything works fine. When i hit the flush only half or little, sometimes the water doesn't stop runnung. The weak never ending waterpulse and it's jitter causes unreliable cleaning operation. The only way to get the flush out of metastability, is to hit the flush hard again. I hope the newer flush systems operate with faster flipflops, so i can save a lot of water. "Peter Alfke" <peter.alfke@xilinx.com> schrieb im Newsbeitrag news:3A37ACD8.F247AED0@xilinx.com... > The Florida election fiasco is a perfect example of metastability. Just > because the result was so very close, the "mechanism" (or lack thereof) > caused a >4 week delay before deciding on one of the two choices. But > let's not get into politics... > > Peter Alfke, Xilinx Applications > ============================================Article: 27921
Jamie Sanderson wrote: > "Damir Danijel Zagar" <damir.zagar@tipro.hr> wrote in message > news:91a2q0$f7va$1@as121.tel.hr... > > I'm starting new FPGA design. In some previous projects I've used > > schematic entry, but for this one I would like to dive into HDL. > > My dilemma is - VERILOG or VHDL. Design is Xilinx Spartan II based. > > What are advantages/disadvantages for both of them? Which one > > to pick up? Thank you for all suggestions. > > > > Damir > > It would be easy to go on at length about the relative merits of each > language, and start a massive debate. My belief is that if you're doing FPGA > design as a profession, you should learn both Verilog and VHDL. > > Still, I recommend VHDL for beginners. As someone else pointed out, Verilog > is easier to make mistakes in. For example, you can assign one signal to > another, even if they aren't of the same width. VHDL considers this a > mistake, and won't compile. > Its interesting that this width thing is always the difference first mentioned in this VHDL/Verilog discussion and its actually misleading. Verilog, at least at the synthesisable level, really only has three data types and no ability for creating any form of structure. wire: Only has a value when driven, defaults to 'z' when not driven reg: retains the last value assigned to it. integer these can be either single bit or [a:b] vectors i.e. wire [a:b] foo; because of this `width' rules can be defined that are very simple. Very approximately [see LRM for details]: if the lhs is wider than the rhs fill the top bits of the lhs with 0's. if the lhs is narrower than the rhs only use the ls bits of the rhs. if the rhs is some complex expression then its width is the width of the largest operand. Some care is needed when mixing reg/wire with integer since the former are considered unsigned and the latter signed. VHDL, by contrast, allows complex derived data types and therefore *needs* strong type checking [Historical question: Which came first, complex types or strong typing ?]. Because Verilog's types are restricted these sort of issues can mostly be taken care of by some careful self-discipline or formal coding styles. If necessary you could invest in one of the `lint' style tools [Anyone know if there's a shareware or GPL'ed one ?]. The **big** thing that bites people with Verilog esp those brought up on VHDL is the blocking/non-blocking assignment thing on which whole tomes have been written. Without care & attention to this its perfectly possible to write Verilog that simulates fine at RTL, synthesises o.k., but whose synth results don't actually match the RTL. Ultimately its not that hard to grasp but it does expose the actions of the simulator, basically the way different classes of event are scheduled becomes visible at the HDL level.Article: 27922
Hi,
I want to provide a header on the board that I am designing that will
allow a single Spartan II (XC2S100) device to be configured manually via
some form of Xilinx cable. The ability to readback configuration data
would be nice, but is not a necessity.
The Spartan II will be wired to be configured in Slave Serial Mode from
a CPLD/ROM, so I think the best way to do this is to provide access to
the JTAG TAP on the header. I would assume the best way to do this is to
provide a jumper that inhibits the automatic configuration by the CPLD
that can be set when you wish to configure via the cable.
Ideally I would want to use an XChecker RS232 cable (DLC4), because I
have access to one of these, but I have a couple of worries about this:
- It appears that the XChecker cable works on 5V only, and although I
will have 5V floating around on my board, I don't know if the 5V cable
will
be happy interfacing with the TAP on a 2.5V Spartan II.
- I read in Xilinx documentation somwhere that the XChecker cable can't
be used for devices larger than 256Kbits, so that is no good for a
~750Kbit device.
Does anyone have any ideas on which would be the best cable to use for
this purpose?
I notice that the interfaces provided by the different cables (XChecker,
Parallel, MultiLINX) are pinned out differently. Is it possible to
provide a 6 pin interface - (VCC, GND, TCK, TMS, TDI, TDO) - that can be
connected to a range of cables for programming?
Are the electrical specifications of the TAP part of the standard, or
are they implementation specific?
Any help on these questions would be greatly appreciated.
Thanks,
Dean Armstrong
The University of Waikato.
Article: 27923Sorry, I ignored to check the /prog pin, but I think the /init pin will automatically be low if /prog is pulled down, and I am sure the /init is high all the time.Article: 27924
Damir,
The truth to the matter is that it doesn't matter which language you go
with, unless you consider certain factors which probably don't apply to you.
At one time, I would have recommended VHDL for FPGA design. The reason
WAS that there were more tools supporting VHDL than Verilog. They were
cheaper, easier to get and relatively common. VHDL tools were cheaper
probably because the VHDL standards committee made it into IEEE standard
1076 in 1987, while Verilog was nowhere near a standard. It was owned by
Gateway Design Automation, which was bought out by Cadence; therefore, most
designers and tools manufacturers considered Verilog as a proprietary
language.
During that time, Verilog was adopted by most of the ASIC industry in
the United States due to its fast gate level simulation, higher levels of
abstraction, introduction by Synopsis of the first Verilog synthesizer
(1988), and Cadence Verilog-XL simulator sign off certification by ASIC
vendors (1989). As you can see, many things caused Verilog to kick off in
the ASIC world in the late 1980s. So the difference between ASICs and FPGAs
back around 1990 was much more pronounced than it is today, not just in gate
count but in the tools suites. FPGAs were the cheapie versions of ASICs,
and along with them came cheapie VHDL tools. I am convinced that the IEEE
standard caused tools vendors to be more efficient and thus produce cheaper
tools. They did this, because Cadence and Synopsis had a stranglehold on
the Verilog language, and VHDL was the only other HDL that could compete
with it.
Then around 1994-1997, things started to turn around in the FPGA world.
The Verilog language was handed over to OVI (Open Verilog International),
which drastically improved the Language Reference Manual, and promoted
Verilog openly to become IEEE standard 1364 in 1995. All of this occurred
mostly due to the HDL war with VHDL. Now that it was an open language and
carried the prestigious IEEE logo, tools vendors started coming out with
Verilog versions of FPGA tools. My personal experience was that most FPGA
tools did not support Verilog until around 1996-1997. But when they did,
they came on like gangbusters.
Today engineers flame each other on which language is better. The
truth is that both languages will do the job. VHDL will do some things
better (e.g. better control of synthesis, error checking, etc.); Verilog
will do other things better (e.g. faster quicky jobs, PLI, etc.). But both
will do the job, and both are supported by most tools today. If you are an
FPGA tool vendor or plan to become one, then you'd better support both HDLs.
A decade ago, there was a true, compelling reason to go with VHDL due
to tools support for FPGAs. Today, the only compelling reason I can think
of to go with an HDL is if you plan to migrate to ASICs. If you are in the
U.S., then Verilog is the preferred ASIC HDL. If you are in Europe, then
VHDL is the preffered HDL. I don't know about the Pacific Rim -- maybe one
or some of our Pacific Rim brothers/sisters can answer that one.
I am glad that both HDLs exist. If you read the brief history given
above, one can understand that it was competition that made both languages
what they are today. Competition resulted in cheaper and better tools,
proliferation of HDL design entry, and better end results.
As an experienced VHDL and Verilog user, I will advise you to select
one of the HDLs and just start using it. If you have to switch later on,
then just do it! You'll have plenty of time to do so before you become a
power user that is stuck in one language.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL
"Damir Danijel Zagar" <damir.zagar@tipro.hr> wrote in message
news:91a2q0$f7va$1@as121.tel.hr...
> I'm starting new FPGA design. In some previous projects I've used
> schematic entry, but for this one I would like to dive into HDL.
> My dilemma is - VERILOG or VHDL. Design is Xilinx Spartan II based.
> What are advantages/disadvantages for both of them? Which one
> to pick up? Thank you for all suggestions.
>
> Damir
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