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
rickman <gnuarm@gmail.com> wrote: >On Jan 10, 1:32=A0pm, "buddylee9898" ><andrewludwig1@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: >> > How much parsing will you need to do of the information from the >> > PHY/MAC? =A0If you just need to do some setup, then read from one memor= >y >> > location over and over (which means that you'd be using low-level >> > Ethernet in some exceedingly simple fashion) then -- maybe. >> >> Essentially, the whole idea of the port is to be sending a constant strea= >m >> of sensor data onto the network at about 8Mbps, and to receive commands t= >o >> change which sensor the data will be coming from, so the sending of data = >is >> fairly constant while the receiving is not. >> >> > You mentioned a "local network" above - you will need to support >> > whatever protocol that network uses. >> >> Yes I will be using a local network which will contain a switch =A0and tw= >o >> computers which will have custom software which should not have to use IP >> addressing, no? But I would like to get back to the point where d_s_klein >> said yes there is a way to receive straight data. I have read the data >> sheet for the ENC28J60, as well as data sheets for a few other chips I wa= >s >> considering, and in reading about them it seems fairly straightforward in >> that you are simply writing data to the chip (write command plus the pack= >et >> data addresses, etc) and reading in a very similar way. Now I have tried = >to >> implement a state machine in order to have this working but without luck = >so >> far. Is this a silly way to try this where there is no way to avoid using >> the picoblaze, or is this feasible to some degree? =A0 =A0 =A0 =A0 >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com > >I can't say much about sending data over Ethernet, but be aware that >the Picoblaze is a VERY minimal processor with a very minimal address >space and program size. If you end up going that route, will it be That depends on the type of FPGA. If you have large blockrams you can write a decent piece of code. Altough the instruction set is small, it is quite effective. If you create some hardware accellerators for common tasks like calculating the CRC, multiplying, etc it can be extremely powerful! -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 150376
On Jan 12, 7:08=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > rickman <gnu...@gmail.com> wrote: > >On Jan 10, 1:32=3DA0pm, "buddylee9898" > ><andrewludwig1@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > >> > How much parsing will you need to do of the information from the > >> > PHY/MAC? =3DA0If you just need to do some setup, then read from one = memor=3D > >y > >> > location over and over (which means that you'd be using low-level > >> > Ethernet in some exceedingly simple fashion) then -- maybe. > > >> Essentially, the whole idea of the port is to be sending a constant st= rea=3D > >m > >> of sensor data onto the network at about 8Mbps, and to receive command= s t=3D > >o > >> change which sensor the data will be coming from, so the sending of da= ta =3D > >is > >> fairly constant while the receiving is not. > > >> > You mentioned a "local network" above - you will need to support > >> > whatever protocol that network uses. > > >> Yes I will be using a local network which will contain a switch =3DA0a= nd tw=3D > >o > >> computers which will have custom software which should not have to use= IP > >> addressing, no? But I would like to get back to the point where d_s_kl= ein > >> said yes there is a way to receive straight data. I have read the data > >> sheet for the ENC28J60, as well as data sheets for a few other chips I= wa=3D > >s > >> considering, and in reading about them it seems fairly straightforward= in > >> that you are simply writing data to the chip (write command plus the p= ack=3D > >et > >> data addresses, etc) and reading in a very similar way. Now I have tri= ed =3D > >to > >> implement a state machine in order to have this working but without lu= ck =3D > >so > >> far. Is this a silly way to try this where there is no way to avoid us= ing > >> the picoblaze, or is this feasible to some degree? =3DA0 =3DA0 =3DA0 = =3DA0 > > >> --------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0 > >> Posted throughhttp://www.FPGARelated.com > > >I can't say much about sending data over Ethernet, but be aware that > >the Picoblaze is a VERY minimal processor with a very minimal address > >space and program size. =A0If you end up going that route, will it be > > That depends on the type of FPGA. If you have large blockrams you can > write a decent piece of code. Altough the instruction set is small, it > is quite effective. If you create some hardware accellerators for > common tasks like calculating the CRC, multiplying, etc it can be > extremely powerful! Unless it has been updated since I looked at it, the constraint on memory size was not the FPGA, but the architecture itself. The PC is only 12 bits or so. Admittedly, 4K is a decent hunk of assembly code to write by hand, but the question is how much code does it take to implement IP, etc. RickArticle: 150377
Hi there, I would like to have access to my chipscope cores via script, in order to have unattended automatic measurements (ila) and parameter variations (vio). for the vio cores chipscope analyzer offers an API with tcl access. ILA is not supported yet, but, according to xilinx, will be supported in ISE 14.1. TCL scripts for JTAG access are available but this is really "lowlevel" and unhandy. I wonder if nobody else has this problem. The best would be to have direct access to the cores via jtag with a high-level scripting language like python. is there any solution?Article: 150378
On Jan 13, 7:12=A0am, rickman <gnu...@gmail.com> wrote: > On Jan 12, 7:08=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > > > > > rickman <gnu...@gmail.com> wrote: <snip> > > > >I can't say much about sending data over Ethernet, but be aware that > > >the Picoblaze is a VERY minimal processor with a very minimal address > > >space and program size. =A0If you end up going that route, will it be > > > That depends on the type of FPGA. If you have large blockrams you can > > write a decent piece of code. Altough the instruction set is small, it > > is quite effective. If you create some hardware accellerators for > > common tasks like calculating the CRC, multiplying, etc it can be > > extremely powerful! > > Unless it has been updated since I looked at it, the constraint on > memory size was not the FPGA, but the architecture itself. =A0The PC is > only 12 bits or so. =A0Admittedly, 4K is a decent hunk of assembly code > to write by hand, but the question is how much code does it take to > implement IP, etc. > > Rick The amount of memory available for the PicoBlaze depends on which version you are using. There are multiple versions targeted at the different Spartan and Virtex generations. I took at some of my code for a PicoBlaze that is part of an offload engine for receiving a custom protocol wrapped in UDP/IP. It was about 1000 lines, about 350 of that was constants and comments. There was minor hardware support to put the headers where the PicoBlaze could read them, in addition to sending the entire packet to a FIFO. A fair amount of the code was for setting up DMA engines, and other stuff. As long as you don't support reassembling fragmented IP packets, or the IP options field, the entire Ethernet/IP/UDP stack is very simple to deal with, and well within reach of a PicoBlaze or a state machine. Regards, John McCaskill www.FasterTechnology.comArticle: 150379
rickman <gnuarm@gmail.com> wrote: >On Jan 12, 7:08=A0pm, n...@puntnl.niks (Nico Coesel) wrote: >> rickman <gnu...@gmail.com> wrote: >> >On Jan 10, 1:32=3DA0pm, "buddylee9898" >> ><andrewludwig1@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: >> >> > How much parsing will you need to do of the information from the >> >> > PHY/MAC? =3DA0If you just need to do some setup, then read from one = >memor=3D >> >y >> >> > location over and over (which means that you'd be using low-level >> >> > Ethernet in some exceedingly simple fashion) then -- maybe. >> >> >> Essentially, the whole idea of the port is to be sending a constant st= >rea=3D >> >m >> >> of sensor data onto the network at about 8Mbps, and to receive command= >s t=3D >> >o >> >> change which sensor the data will be coming from, so the sending of da= >ta =3D >> >is >> >> fairly constant while the receiving is not. >> >> >> > You mentioned a "local network" above - you will need to support >> >> > whatever protocol that network uses. >> >> >> Yes I will be using a local network which will contain a switch =3DA0a= >nd tw=3D >> >o >> >> computers which will have custom software which should not have to use= > IP >> >> addressing, no? But I would like to get back to the point where d_s_kl= >ein >> >> said yes there is a way to receive straight data. I have read the data >> >> sheet for the ENC28J60, as well as data sheets for a few other chips I= > wa=3D >> >s >> >> considering, and in reading about them it seems fairly straightforward= > in >> >> that you are simply writing data to the chip (write command plus the p= >ack=3D >> >et >> >> data addresses, etc) and reading in a very similar way. Now I have tri= >ed =3D >> >to >> >> implement a state machine in order to have this working but without lu= >ck =3D >> >so >> >> far. Is this a silly way to try this where there is no way to avoid us= >ing >> >> the picoblaze, or is this feasible to some degree? =3DA0 =3DA0 =3DA0 = >=3DA0 >> >> >> --------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0 >> >> Posted throughhttp://www.FPGARelated.com >> >> >I can't say much about sending data over Ethernet, but be aware that >> >the Picoblaze is a VERY minimal processor with a very minimal address >> >space and program size. =A0If you end up going that route, will it be >> >> That depends on the type of FPGA. If you have large blockrams you can >> write a decent piece of code. Altough the instruction set is small, it >> is quite effective. If you create some hardware accellerators for >> common tasks like calculating the CRC, multiplying, etc it can be >> extremely powerful! > >Unless it has been updated since I looked at it, the constraint on >memory size was not the FPGA, but the architecture itself. The PC is >only 12 bits or so. Admittedly, 4K is a decent hunk of assembly code >to write by hand, but the question is how much code does it take to >implement IP, etc. If you stay away from tcp/ip it is very feasible to implement the UDP and ARP parts of the IP protocol. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 150380
I am finally going to learn Verilog for real after using VHDL for 15 years. I've done a little work with Verilog and found it relatively easy to use. Now I want to learn the details and especially how not to make mistakes. VHDL has the problem of not letting you do things unless you make it explicitly clear what you want to do. My understanding is that Verilog will let you not specify fully what you want without complaining, but you have to know what the default behavior will be in those situations or it may not happen the way you expect. This is what I need detailed info on. Otherwise I am looking for something that covers synthesis well and include info on writing test benches. I have "HDL Chip Design" by Douglas Smith, third printing 1997. This book covers both VHDL and Verilog, side by side, but has an odd style and often does not cover all the details of a topic clearly. There are times I can only find the info I want if I analyze the example code very, very carefully. Searching here I found recommendations for "The Verilog=AE Hardware Description Language", Donald E. Thomas and "HDL Programming Fundamentals: VHDL and Verilog", Nazeih Botros. The former appears to be a bit long in the tooth and the latest edition (which is the only one covering the 2001 revision of the standard) is quite pricey. The latter is another dual book comparing VHDL and Verilog side by side. I don't know about its organization. What do the Verilog users recommend in my case? Why do you like the books you like? RickArticle: 150381
On Fri, 14 Jan 2011 08:44:28 -0800 (PST), rickman wrote: > What do the Verilog users recommend in my case? > Why do you like the books you like? Rick, I've always found that Verilog is nowhere near so well served by textbooks as VHDL. I can speculate why that is, but I don't know for sure. I haven't met ANY book on Verilog for design that I really like. Since you've been doing this for a loooong time and you know exactly what to expect from HDL synthesis, you may find it better to pick up the basics by osmosis (you probably did that already) and then go for a more advanced tips-and-tricks book like Stu Sutherland and Don Mills's Verilog and SystemVerilog Gotchas. For testbenches, it's hard to beat the second edition of Janick Bergeron's Writing Testbenches. That one covers both VHDL and Verilog, but it's a goldmine of good sense and useful ideas. There's also an "edition 2.5" called Writing Testbenches in SystemVerilog, or something like that; it's OK but you probably want to get a good feel for more traditional testbench writing styles before you attack SystemVerilog's bottomless pit. There are interesting things you can do with Verilog testbenches that you simply can't begin to do in VHDL, so you'll probably want to mess around with some of Janick's examples and see what parts of it can be made to work for you. There are good resources on Cliff Cummings' website www.sunburst-design.com although, as reported here on many occasions, I profoundly disagree with some of Cliff's conclusions about good style. Again, you're plenty experienced enough to make up your own mind about such things. Finally, you'll also encounter things that you have been able to do easily in VHDL but are devil-hard or just plain impossible in Verilog, especially when it comes to designing parameterizable blocks. And you'll have to decide just how to soothe your conscience after you start using the Verilog macro preprocessor. And another thing... In VHDL you got frustrated with the clunky syntax and restrictive rules for doing arithmetic on vectors, right? And it'll all be so much easier in Verilog, with hardly any red tape. But you forget at your peril the arcane and complex rules about arithmetic bit-width in Verilog. Trawling back through the comp.lang.verilog archives in search of wisdom from Steven Sharp will save you much pain. Good luck -- Jonathan BromleyArticle: 150382
On Jan 14, 11:44=A0am, rickman <gnu...@gmail.com> wrote: > I am finally going to learn Verilog for real after using VHDL for 15 > years. =A0I've done a little work with Verilog and found it relatively > easy to use. =A0Now I want to learn the details and especially how not > to make mistakes. > > VHDL has the problem of not letting you do things unless you make it > explicitly clear what you want to do. =A0My understanding is that > Verilog will let you not specify fully what you want without > complaining, but you have to know what the default behavior will be in > those situations or it may not happen the way you expect. =A0This is > what I need detailed info on. > > Otherwise I am looking for something that covers synthesis well and > include info on writing test benches. > > I have "HDL Chip Design" by Douglas Smith, third printing 1997. =A0This > book covers both VHDL and Verilog, side by side, but has an odd style > and often does not cover all the details of a topic clearly. =A0There > are times I can only find the info I want if I analyze the example > code very, very carefully. > > Searching here I found recommendations for "The Verilog=AE Hardware > Description Language", Donald E. Thomas and "HDL Programming > Fundamentals: VHDL and Verilog", Nazeih Botros. =A0The former appears to > be a bit long in the tooth and the latest edition (which is the only > one covering the 2001 revision of the standard) is quite pricey. =A0The > latter is another dual book comparing VHDL and Verilog side by side. > I don't know about its organization. > > What do the Verilog users recommend in my case? =A0Why do you like the > books you like? > > Rick As Jonathan (a true HDL guru) pointed out it's not easy to find good texts on Verilog. I started in by modifying and adding to existing projects (our company has adopted Verilog almost exclusively) and then went back and read through Thomas & Moorby's book, an old text that predates Verilog 2001. While I don't think the book would have been a good text without the initial dabbling in Verilog, it definitely cleared up some concepts in my mind like blocking and non-blocking assignments and the syntax of # delays. Having already written in VHDL for some years you should be able to pick this up quickly, since there are similar concepts in VHDL (signals v. variables). I also find it handy to have a good language reference. The official LRM is a bit dry and unfriendly, but makes the expected workings clear (as mud). However I generally refer to the Doulos "Verilog Golden Reference Guide" when I need to look up some obscure syntax that I don't use often, and sometimes just to browse through and find constructs I've never come across before. It is well organized and includes examples and "gotcha's" for most of the entries. It would be nice if someone wrote a good book on synthesizable Verilog with coding examples, but unfortunately that seems to be a moving target as many synthesis tools add more language coverage over time. If you're designing with Xilinx, you can also glean some useful information from the XST user's guide, which gives some templates for synthesizing into FPGA features like memory and shift registers. Good luck on your transformation, GaborArticle: 150383
On Jan 13, 9:58=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > On Jan 13, 7:12=A0am, rickman <gnu...@gmail.com> wrote: > > > On Jan 12, 7:08=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > > > > rickman <gnu...@gmail.com> wrote: > > <snip> > > > > > > > > >I can't say much about sending data over Ethernet, but be aware that > > > >the Picoblaze is a VERY minimal processor with a very minimal addres= s > > > >space and program size. =A0If you end up going that route, will it b= e > > > > That depends on the type of FPGA. If you have large blockrams you can > > > write a decent piece of code. Altough the instruction set is small, i= t > > > is quite effective. If you create some hardware accellerators for > > > common tasks like calculating the CRC, multiplying, etc it can be > > > extremely powerful! > > > Unless it has been updated since I looked at it, the constraint on > > memory size was not the FPGA, but the architecture itself. =A0The PC is > > only 12 bits or so. =A0Admittedly, 4K is a decent hunk of assembly code > > to write by hand, but the question is how much code does it take to > > implement IP, etc. > > > Rick > > The amount of memory available for the PicoBlaze depends on which > version you are using. There are multiple versions targeted at the > different Spartan and Virtex generations. So what is the most memory available for the Picoblaze. When I looked at using the Picoblaze, one of the things I didn't like was that it was all instantiated logic. There were no parameters to tweek and any changes to the architecture would require a new assembler. That's why I rolled my own. It was a little bigger, but I thought it was much better and ran fairly fast, over 50 MHz. I don't recall how fast the Picoblaze is. I seem to recall that the instruction set is rather stunted and the processor has relatively few registers. But then I haven't looked at it in years. It would be nice if they had a short document that explained the basic architectural features without a lot of noise. RickArticle: 150384
I dont think you should have much problem learning Verilog as I found it easier than VHDL. I would read some of the articles at Sunburst design as they explain some of the problems you might encounter like blocking vs non blocking. I wouldnt bother buying any books as you can get most info off the internet. Regards Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150385
"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote
in message news:TqednQam6MfNN63QnZ2dnUVZ_g-dnZ2d@giganews.com...
> I dont think you should have much problem learning Verilog as
> I found it easier than VHDL. I would read some of the articles
> at Sunburst design as they explain some of the problems you might
> encounter like blocking vs non-blocking. I wouldnt bother buying
> any books as you can get most info off the internet. Regards
> Jon
> ---------------------------------------
> Posted through http://www.FPGARelated.com
I agree with Jon, in that you have prior knowledge in the art,
but, if you are like me, learning from scratch for a particular
device, I bought this:
"FPGA PROTOTYPING BY VERILOG EXAMPLES"
'XILINX SPARTAN™-3 VERSION'
PONG P. CHU
It is very informative, and helps you build things properly.
I got mine through my sister, who works at Baker and Taylor.
Bill
Article: 150386On Jan 14, 4:44=A0pm, rickman <gnu...@gmail.com> wrote: > I am finally going to learn Verilog for real after using VHDL for 15 > years. =A0I've done a little work with Verilog and found it relatively > easy to use. =A0Now I want to learn the details and especially how not > to make mistakes. > > VHDL has the problem of not letting you do things unless you make it > explicitly clear what you want to do. =A0My understanding is that > Verilog will let you not specify fully what you want without > complaining, but you have to know what the default behavior will be in > those situations or it may not happen the way you expect. =A0This is > what I need detailed info on. > I also did a VHDL to Verilog transition a few years back. The two key points have been mentioned in this thread already - default arithmetic rules and blocking/non-blocking. The former is a bit of a pig. The rules that deal with arithmetic over different bit widths and signed/unsigned values are just a big hack in my opinion (accumulated over 30 years). I generally ignore them and use explicit wire declarations when they are needed. This is a nice thing in Verilog - you don't need to declare a signal first and then assign to it later on - you can make new 'wires' at any point in your code. Generally this means when I would need a conversion function in VHDL to make my types or bit widths match I will introduce a new 'wire'. The rules become much simpler to comprehend because of this. The blocking/non-blocking thing simply requires restraint - there are lots of coding styles that will work in Verilog. That said it's perfectly reasonable to use '<=3D' and '=3D' in a manner that matches VHDL's '<=3D' and ':=3D' assignments. The only difference is that in VHDL signals and variables are distinct entities and therefore the compiler can tell you when you have made a mistake. Verilog can't, but its not really that difficult to be a good citizen in this case. I would also dispute the assertion that Verilog lack parameterization capabilities. At the module level Verilog is just as capable as VHDL. Functions and procedures are much more flexible in VHDL, however. On the other hand testbenches are dramatically easier in Verilog. For all it's many faults I prefer Verilog to VHDL because of this. Personally I think both languages are hugely flawed so I wrote my own. -AndyArticle: 150387
On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote: >The former is a bit of a pig. The rules that deal with arithmetic >over different bit widths and signed/unsigned values are just a big >hack in my opinion (accumulated over 30 years). I agree it's a pig - frighteningly easy to get wrong - but I'm not entirely sure its design is as bad as you imply. There are many possible choices for how to deal with arbitrary-precision arithmetic, and I'm fairly certain that there is *no* choice that will give the intuitively correct behaviour for everyone in every case. Some of the options are: - Permit unlimited bit growth of expressions so that the mathematical intent is preserved in all situations, narrowing only on final copy into a target object. This sounds nice, but doesn't sit nicely with the bounded sizes of physical hardware, so it may force you into generating a lot of explicit intermediate variables to model real hardware's behaviour (although I sense that you may feel this to be a good thing rather than a disadvantage). - Have every operation return a result whose bit width is determined solely by the operand widths and the operation (VHDL). This has the huge advantage of being relatively easy to define and understand, but leads to nonsenses in practice; either you get the carry-out from an add, in which case it's too wide to put back into one of the operand variables, or you throw away the carry as numeric_std does. Either way, some users will be forced into doing non-obvious things to get the results they want. - Have context-determined size rules. Verilog does this, and provides a fine example of how hard (impossible?) it is to get all the rules right so that people don't get nasty surprises. It really isn't easy to make clear, reproducible rules that do The Right Thing for everyone's needs. I'm not saying that either VHDL or Verilog have it exactly right, but each has an internal consistency that's fairly satisfying and comprehensible once you're used to it. > I generally ignore [the bit width rules] >and use explicit wire declarations when they are needed. This is >a nice thing in Verilog - you don't need to declare a signal first and >then assign to it later on - you can make new 'wires' at any point in >your code. Generally this means when I would need a conversion >function in VHDL to make my types or bit widths match I will introduce >a new 'wire'. The rules become much simpler to comprehend because of >this. That's a useful idea, but it does push you into a style of coding that's perhaps unnecessarily explicit and verbose. [snip good sense about blocking/nonblocking] >I would also dispute the assertion that Verilog lack parameterization >capabilities. At the module level Verilog is just as capable as >VHDL. I really don't think this is true, although V-2001 "generate" plugs some of the most gaping holes. Since 2005 Verilog has had a clear definition of "constant function". Along with SystemVerilog's ability to give arbitrary data types to parameters, this makes things much better because you can now compute parameter values in a reasonably complicated way if you wish - just as you've been able to do in VHDL since forever. It's too little too late, though, and it's still at the mercy of tool support in synthesis. And, as you also point out, the power of VHDL's unconstrained subprogram arguments has no match in Verilog; that has an impact on design parameterization too. >testbenches are dramatically easier in Verilog. It's hard to disagree with this. >Personally I think both languages are hugely flawed so I wrote my own. What specific flaws have you overcome, and what new ones have you introduced? :-) -- Jonathan BromleyArticle: 150388
Jonathan Bromley wrote:
> On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote:
>
>> The former is a bit of a pig. The rules that deal with arithmetic
>> over different bit widths and signed/unsigned values are just a big
>> hack in my opinion (accumulated over 30 years).
>
> I agree it's a pig - frighteningly easy to get wrong - but
> I'm not entirely sure its design is as bad as you imply.
>
> There are many possible choices for how to deal with
> arbitrary-precision arithmetic, and I'm fairly certain
> that there is *no* choice that will give the intuitively
> correct behaviour for everyone in every case. Some of
> the options are:
>
> - Permit unlimited bit growth of expressions so that the
> mathematical intent is preserved in all situations,
That's what MyHDL does, and I believe it is the intuitively
correct behavior for arithmetic.
> narrowing only on final copy into a target object.
MyHDL doesn't do this: it checks whether the value is
within the stated target bounds and gives you a run-time
error when it's not. It never throws anything away
silently.
> This sounds nice, but doesn't sit nicely with the
> bounded sizes of physical hardware, so it may force
> you into generating a lot of explicit intermediate
> variables to model real hardware's behaviour
I don't get this. After debugging, the target objects
do have adequate bit widths. A synthesis tool can
optimize away any logic not required to fill those bits.
> (although I sense that you may feel this to be
> a good thing rather than a disadvantage).
>
> - Have every operation return a result whose bit width
> is determined solely by the operand widths and the
> operation (VHDL). This has the huge advantage of being
> relatively easy to define and understand, but leads to
> nonsenses in practice; either you get the carry-out from
> an add, in which case it's too wide to put back into
> one of the operand variables, or you throw away the
> carry as numeric_std does. Either way, some users will
> be forced into doing non-obvious things to get the
> results they want.
>
> - Have context-determined size rules. Verilog does this,
> and provides a fine example of how hard (impossible?)
> it is to get all the rules right so that people don't
> get nasty surprises.
>
> It really isn't easy to make clear, reproducible rules
> that do The Right Thing for everyone's needs. I'm not
> saying that either VHDL or Verilog have it exactly right,
> but each has an internal consistency that's fairly
> satisfying and comprehensible once you're used to it.
--
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.com
Article: 150389
Gabor wrote:
> On Jan 14, 11:44 am, rickman <gnu...@gmail.com> wrote:
>> I am finally going to learn Verilog for real after using VHDL for 15
>> years. I've done a little work with Verilog and found it relatively
>> easy to use. Now I want to learn the details and especially how not
>> to make mistakes.
>>
>> VHDL has the problem of not letting you do things unless you make it
>> explicitly clear what you want to do. My understanding is that
>> Verilog will let you not specify fully what you want without
>> complaining, but you have to know what the default behavior will be in
>> those situations or it may not happen the way you expect. This is
>> what I need detailed info on.
>>
>> Otherwise I am looking for something that covers synthesis well and
>> include info on writing test benches.
>>
>> I have "HDL Chip Design" by Douglas Smith, third printing 1997. This
>> book covers both VHDL and Verilog, side by side, but has an odd style
>> and often does not cover all the details of a topic clearly. There
>> are times I can only find the info I want if I analyze the example
>> code very, very carefully.
>>
>> Searching here I found recommendations for "The Verilog® Hardware
>> Description Language", Donald E. Thomas and "HDL Programming
>> Fundamentals: VHDL and Verilog", Nazeih Botros. The former appears to
>> be a bit long in the tooth and the latest edition (which is the only
>> one covering the 2001 revision of the standard) is quite pricey. The
>> latter is another dual book comparing VHDL and Verilog side by side.
>> I don't know about its organization.
>>
>> What do the Verilog users recommend in my case? Why do you like the
>> books you like?
>>
>> Rick
>
> As Jonathan (a true HDL guru) pointed out it's not easy to find good
> texts
> on Verilog. I started in by modifying and adding to existing projects
> (our
> company has adopted Verilog almost exclusively) and then went back
> and read through Thomas & Moorby's book, an old text that predates
> Verilog 2001. While I don't think the book would have been a good
> text
> without the initial dabbling in Verilog, it definitely cleared up some
> concepts
> in my mind like blocking and non-blocking assignments
That I find really surprizing: my assessment about that book
is totally different.
Thomas & Moorby, The Verilog Hardware Description Language,
5th edition, 2002 (updated to Verilog 2001)
===========================================================
1. Blocking assignments
-----------------------
2. The role of synthesis
------------------------
p.51 """All procedural assignments in an always block must
either be blocking or non-blocking assignments. They cannot
be mixed ... Although descriptions using the regular "="
will synthesize properly, they may not simulate properly.
Since both simulation and synthesis are generally of
importance, use "<=" for edge sensitive circuits."""
This is a combination of two common fallacies. First, about
the use of blocking assignments: not making the difference
between synchronous communication (problematic) and
local computation (a good idea). Second, about the role
of synthesis: it is meaningless to make statements about
synthesis when a model doesn't simulate properly.
3. Blocking assignments (contradiction)
--------------------------------------
p.197 """The use of blocking and non-blocking assignments was
mixed in this specification. Non-blocking assignments were used
for registers which are used outside of the always block. For
registers used only in one always block this is not necessary ...
you can use blocking assignments to calculate intermediate
values and values only used inside the always block."""
Perfect! If only more designers would make it to this chapter :-)
The problem here is that it contradicts 1) above. Such a
contradiction within the same publication is an error in
its own right.
4. Non-blocking assignments
---------------------------
p.205 """When using cycle-accurate specification, only one
non-blocking assignment is made to any member of the output
set in a state. If two such assignments were made to a
register, its final value would be indeterminate."""
Note: "state" in this context means the code between
clock events.
This is wrong: The last non-blocking assignment wins.
Note that this is an essential feature in RTL modeling,
for the efficient modeling of default values.
5. The nature of a reg
----------------------
p.329 """Registers are abstractions of storage devices
found in digital systems. They are defined with the
reg keyword ..."""
Linking Verilog regs to "an abstraction of storage
devices" is flawed. This is not how Verilog works and
makes it harder to understand the language.
----------------------------------------------------------
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.com
Article: 150390On Jan 15, 10:38=A0am, Jonathan Bromley <s...@oxfordbromley.plus.com> wrote: > On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote: > >The former is a bit of a pig. =A0The rules that deal with arithmetic > >over different bit widths and signed/unsigned values are just a big > >hack in my opinion (accumulated over 30 years). > > I agree it's a pig - frighteningly easy to get wrong - but > I'm not entirely sure its design is as bad as you imply. > Maybe the best has been made of what I consider a bad idea in the first place. Unfortunately, the inherent complexity in the Verilog design doesn't just burn designers, but also tool vendors where occasional synthesis/simulation mismatches have led to many, many hours of head scratching and refactoring. At least thats my experience. > > =A0I generally ignore [the bit width rules] > >and use explicit wire declarations when they are needed. =A0This is > >a nice thing in Verilog - you don't need to declare a signal first and > >then assign to it later on - you can make new 'wires' at any point in > >your code. =A0Generally this means when I would need a conversion > >function in VHDL to make my types or bit widths match I will introduce > >a new 'wire'. =A0The rules become much simpler to comprehend because of > >this. > > That's a useful idea, but it does push you into a style of > coding that's perhaps unnecessarily explicit and verbose. Yes, it is a little bit more verbose, but if it leads to code I can read and understand more easily (and that makes things a bit more explicit for the toolchain), I find that worthwhile. You may disagree and think that less verbose code more desirable and I think that's a valid point too. Probably the sweet spot is somewhere in the middle. > > >I would also dispute the assertion that Verilog lack parameterization > >capabilities. =A0At the module level Verilog is just as capable as > >VHDL. > > I really don't think this is true, although V-2001 "generate" > plugs some of the most gaping holes. > Probably the one place where VHDL has a clear practical advantage in my mind is the ability to parameterize the port map of a circuit using functions and/or constants from packages. But I tend to find that just makes Verilog a bit more verbose, not less useful as such. > synthesis. =A0And, as you also point out, the power of VHDL's > unconstrained subprogram arguments has no match in Verilog; > that has an impact on design parameterization too. Yes, that's a big win for VHDL, however, Verilog does have the ability to parameterize functions if you package them into an (otherwise empty) module. It's not quite the same thing, but still useful on occasion. > >Personally I think both languages are hugely flawed so I wrote my own. > > What specific flaws have you overcome, and what new ones have > you introduced? :-) Obviously I am hugely biased, but ... - Parameterization is terribly verbose in both languages and quite limited. - Static typing in VHDL is, again, very verbose compared to what can be achieved using 40 year old technology (Hindley-Milner based type systems). - Most importantly I have a deep dislike of having to maintain a golden model in a wholly different language in order to test my designs. My solution (actually, I can't take any credit for the general approach) is to embed an HDL in a general purpose functional language (ocaml) and build a toolset around that. Now my parameterization language is a full industrial strength programming language. So is my testbench language. I can write everything including my golden model, RTL and testbench in one language and I have found this leads to much more automatic self checking testbenches which can pinpoint errors quickly and easily without staring at waveforms all the time. It also tickles a particular interest of mine in that it's possible to build mini-compilers which target particular types of hardware. That is I can write abstract specifications of systems and then compile then into different hardware architectures. Good luck trying that in Verilog! Flaws? The intersection between people interested in functional programming and hardware design is, well, miniscule and is probably mainly made up of people with 'professor' in their title. Also, as an embedded language (or at least given it's current implementation) it can be quite hard to relate information from later parts in the toolchain back to the original source code ie finding the code related to a critical path from the synthesizer. -AndyArticle: 150391
On Jan 15, 12:33=A0pm, "evilkid...@googlemail.com" <evilkid...@gmail.com> wrote: > On Jan 15, 10:38=A0am, Jonathan Bromley <s...@oxfordbromley.plus.com> > wrote: > > > On Fri, 14 Jan 2011 19:52:07 -0800 (PST), evilkidder wrote: > > >The former is a bit of a pig. =A0The rules that deal with arithmetic > > >over different bit widths and signed/unsigned values are just a big > > >hack in my opinion (accumulated over 30 years). > > > I agree it's a pig - frighteningly easy to get wrong - but > > I'm not entirely sure its design is as bad as you imply. > > Maybe the best has been made of what I consider a bad idea in the > first place. =A0Unfortunately, the inherent complexity in the Verilog > design doesn't just burn designers, but also tool vendors where > occasional synthesis/simulation mismatches have led to many, many > hours of head scratching and refactoring. =A0At least thats my > experience. > > > > =A0I generally ignore [the bit width rules] > > >and use explicit wire declarations when they are needed. =A0This is > > >a nice thing in Verilog - you don't need to declare a signal first and > > >then assign to it later on - you can make new 'wires' at any point in > > >your code. =A0Generally this means when I would need a conversion > > >function in VHDL to make my types or bit widths match I will introduce > > >a new 'wire'. =A0The rules become much simpler to comprehend because o= f > > >this. > > > That's a useful idea, but it does push you into a style of > > coding that's perhaps unnecessarily explicit and verbose. > > Yes, it is a little bit more verbose, but if it leads to code I can > read and understand more easily (and that makes things a bit more > explicit for the toolchain), I find that worthwhile. =A0You may disagree > and think that less verbose code more desirable and I think that's a > valid point too. =A0Probably the sweet spot is somewhere in the middle. This is starting to sound like VHDL...! I don't mind being explicit. It is just that in VHDL it can get rather confusing as to what you need to be explicit about or how exactly to be explicit. I find it hard to believe that there are no good texts on this. In 1995 or thereabout when I was first learning VHDL, I found the texts to be a bit lacking not to mention few. I originally thought that once I had gotten to a point where I could write the stuff, I would write a book explaining how to code VHDL without learning all the bloody details. By the time I got ready to consider it, a bazillion books had come out, so instead I bought a couple. If the good Verilog text field is really sparse, maybe I should tackle that one instead... RickArticle: 150392
> The VHDL part has been synthesised using Synplify, producing well- > looking EDIF. Then, I tried to compile (and I hoped then to P&R) the > two .edn files using Actel Designer. However, here comes the failure. One thing worth noting -- in the options for Synplify, you can make it output tech-mapped Verilog or tech-mapped VHDL. I tend to use those options, myself, when debugging designs, and it sounds like doing so in your case could you help to find the source of the disconnected instances. regards, KrisArticle: 150393
I have VHDL code that creates a tapped delay line, using the carry
chain of a spartan3 chip. The cells (up to 128) are created in a
generate loop:
gen_delaychain: for i in 0 to N-1 generate
delaycell_inst : delaycell port map (
clock => clock,
cin => cy(i),
cout => cy(i+1),
cout_reg => cy_reg(i));
end generate;
As the delay chain has to run vertically through the chip (Spartan3E),
I have RLOC constraints in the UCF file:
INST "gen_delaychain[0].delaycell_inst/MUXCY_1" RLOC="X0Y0";
INST "gen_delaychain[1].delaycell_inst/MUXCY_1" RLOC="X0Y0";
INST "gen_delaychain[2].delaycell_inst/MUXCY_1" RLOC="X0Y1";
INST "gen_delaychain[2].delaycell_inst/MUXCY_1" RLOC="X0Y1";
... and so on.
First question:
Is it possible to define these contraints in the VHDL code, in the
generate loop so that I don't have to write lots of these lines?
Second question:
Is it possible to have these RLOC constraints so that the carry chain
runs vertically through the chip, and have at the same time an absolute
LOC constraint for one of these cells to specify the absolute location
of the whole chain?
Third question:
If I want to use more than one of these carry chains, how can I specify
the relative location of the cells in each chain, but let ISE determine
the y-position of the chains itself?
Thanks,
Thomas
Article: 150394Thomas Heller wrote: > I have VHDL code that creates a tapped delay line, using the carry > chain of a spartan3 chip. The cells (up to 128) are created in a > generate loop: I have no answer for your questions, but are you sure it is a good idea to use a delay line with a chain of gates? I've read that the delay can change very much with temperature, voltage or different batches for your FPGA (if you need it for a product). And it changes each time you change your VHDL program and the routing is different, but maybe you can solve this with your location constraints. -- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbussArticle: 150395
Am 16.01.2011 20:23, schrieb Frank Buss: > Thomas Heller wrote: > >> I have VHDL code that creates a tapped delay line, using the carry >> chain of a spartan3 chip. The cells (up to 128) are created in a >> generate loop: > > I have no answer for your questions, but are you sure it is a good idea to > use a delay line with a chain of gates? I've read that the delay can change > very much with temperature, voltage or different batches for your FPGA (if > you need it for a product). And it changes each time you change your VHDL > program and the routing is different, but maybe you can solve this with > your location constraints. > Of course the whole chain must be calibrated, and changes in prop-delay depending on temperature or voltage must be compensated. I'm trying to do high-resolution timing measurements with 100ps or so resolution, as described in several papers. One example is this: http://lss.fnal.gov/archive/2009/pub/fermilab-pub-09-608-e.pdf ThomasArticle: 150396
Thomas Heller wrote: > Of course the whole chain must be calibrated, and changes in prop-delay > depending on temperature or voltage must be compensated. > > I'm trying to do high-resolution timing measurements with 100ps or so > resolution, as described in several papers. One example is this: > > http://lss.fnal.gov/archive/2009/pub/fermilab-pub-09-608-e.pdf Thanks, looks interesting. -- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbussArticle: 150397
Thomas Heller <theller@ctypes.org> wrote: >Am 16.01.2011 20:23, schrieb Frank Buss: >> Thomas Heller wrote: >> >>> I have VHDL code that creates a tapped delay line, using the carry >>> chain of a spartan3 chip. The cells (up to 128) are created in a >>> generate loop: >> >> I have no answer for your questions, but are you sure it is a good idea to >> use a delay line with a chain of gates? I've read that the delay can change >> very much with temperature, voltage or different batches for your FPGA (if >> you need it for a product). And it changes each time you change your VHDL >> program and the routing is different, but maybe you can solve this with >> your location constraints. >> >Of course the whole chain must be calibrated, and changes in prop-delay >depending on temperature or voltage must be compensated. > >I'm trying to do high-resolution timing measurements with 100ps or so >resolution, as described in several papers. One example is this: If the inputsignal you are measuring consists of many events you could try to use the delay line in the DCM to create a sampler by changing the phase a little. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 150398
On 1/15/2011 12:09 PM, rickman wrote:
> This is starting to sound like VHDL...! I don't mind being explicit.
> It is just that in VHDL it can get rather confusing as to what you
> need to be explicit about or how exactly to be explicit.
>
> I find it hard to believe that there are no good texts on this.
It is true.
I found this one slightly useful:
http://www.google.com/search?q=botros+isbn+1584508558
It's the only book of side by side vhdl|verilog examples in print.
But that is all it is -- simple synthesis examples and a short
explanation. No language reference or simulation examples.
But it's a quick way for a vhdl guy to get started
on verilog synthesis, and the price is right.
> In
> 1995 or thereabout when I was first learning VHDL, I found the texts
> to be a bit lacking not to mention few. I originally thought that
> once I had gotten to a point where I could write the stuff, I would
> write a book explaining how to code VHDL without learning all the
> bloody details. By the time I got ready to consider it, a bazillion
> books had come out, so instead I bought a couple. If the good Verilog
> text field is really sparse, maybe I should tackle that one instead...
Maybe, but do it for fun, not for money.
-- Mike Treseler
Article: 150399Am 16.01.2011 22:10, schrieb Nico Coesel: > Thomas Heller<theller@ctypes.org> wrote: >> I'm trying to do high-resolution timing measurements with 100ps or so >> resolution, as described in several papers. One example is this: > > If the inputsignal you are measuring consists of many events you could > try to use the delay line in the DCM to create a sampler by changing > the phase a little. > The inputsignal is not repetetive (sp?), so this is not possible. Thomas
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