Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Sun, 16 Jan 2011 20:04:04 +0100, Thomas Heller <theller@ctypes.org> 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: >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? Here is one paper describing roughly this approach. http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/place1.htm Linked from http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/top.htm which may have more information. - BrianArticle: 150401
Thomas Heller <theller@ctypes.org> wrote: (snip) > 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 Sounds prety neat, though, as it says, you need to do the complete calibration. Some years ago I worked with an analog ASIC based TDC that (as I understand it), it charged a capacitor at constant current starting at the input pulse, and ending at the clock. Then the voltage is measured with an ADC. I don't remember now (it was built into the ASIC, and I didn't have anything to do with that) how it kept the calibration right. That is, it was an 8 bit ADC, with full scale at the clock frequency. It supplied the low bits, a counter at 66MHz supplied the high order bits. Maybe a PLL to adjust the current. It seems to me that you need FF's with a known time, or at least constant delay, from the carry chain taps. I don't remember seeing that in your macros, but I wasn't looking for them, either. A thought that I didn't see in the Fermilab paper, and maybe won't work: Use the delay through the whole delay line (or another one in the same FPGA) to adjust the voltage and/or temperature to keep the delay constant. Also, maybe you can work with the DCM in the FPGA. -- glenArticle: 150402
Thomas Heller <theller@ctypes.org> wrote: >Am 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. Then you do have a time consuming problem :-) Did you think about placing the delay lines by hand by using the floorplan editor? I'd try to fixate the delay lines as much as possible and have ISE route the rest of the circuits around it. You could write a piece of software to generate the UCF files. This would save a lot of typing and it is easy to change. I have used that method for a design which used a very complicated multiplexing scheme which was stored in a blockram. It would also be nice if you could have the delay lines in a seperate netlist which is included during build (like an IP core). You could also generate this together with the UCF files. Then the whole delay line block(s) are just drop-in objects. It might take some time to figure it out but it might be cleaner and more reproducable than using VHDL. Another pitfall is the optimizer; it should not be allowed to optimize the delay lines. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 150403
Nico Coesel <nico@puntnl.niks> wrote: (snip) > It would also be nice if you could have the delay lines in a seperate > netlist which is included during build (like an IP core). You could > also generate this together with the UCF files. Then the whole delay > line block(s) are just drop-in objects. It might take some time to > figure it out but it might be cleaner and more reproducable than using > VHDL. Another pitfall is the optimizer; it should not be allowed to > optimize the delay lines. In the XC4000 days, I remember using RPMs from verilog. I would write a dummy (empty) module, or maybe with very simple logic. Generate the netlist, then, in a step I don't remember exactly, replace the dummy module with the RPM. The result then goes into P&R as usual. The PRM includes relative positioning, and also specific carry chain use, but otherwise can be moved around by P&R. -- glenArticle: 150404
On Jan 16, 2:04=A0pm, Thomas Heller <thel...@ctypes.org> wrote: > I have VHDL code that creates a tapped delay line, using the carry > chain of a spartan3 chip. =A0The cells (up to 128) are created in a > generate loop: > > =A0 =A0gen_delaychain: for i in 0 to N-1 generate > =A0 =A0 =A0delaycell_inst : delaycell port map ( > =A0 =A0 =A0 =A0clock =A0 =A0=3D> clock, > =A0 =A0 =A0 =A0cin =A0 =A0 =A0=3D> cy(i), > =A0 =A0 =A0 =A0cout =A0 =A0 =3D> cy(i+1), > =A0 =A0 =A0 =A0cout_reg =3D> cy_reg(i)); > =A0 =A0end generate; > > As the delay chain has to run vertically through the chip (Spartan3E), > I have RLOC constraints in the UCF file: > > =A0 =A0INST "gen_delaychain[0].delaycell_inst/MUXCY_1" RLOC=3D"X0Y0"; > =A0 =A0INST "gen_delaychain[1].delaycell_inst/MUXCY_1" RLOC=3D"X0Y0"; > =A0 =A0INST "gen_delaychain[2].delaycell_inst/MUXCY_1" RLOC=3D"X0Y1"; > =A0 =A0INST "gen_delaychain[2].delaycell_inst/MUXCY_1" RLOC=3D"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 Interesting. I am currently working on something similar using an external programmable delay line. I looked at the paper, but I'm not sure I understand exactly what you are trying to measure really. I guess my concern would not be the issues of timing consistency in the active portions like the carry chain. Rather my concern would be the routing. If you look at a typical timing report, much if not most of a delay is in the routing. This can be minimized, but that is the issue. If you don't hand place at least, and better yet, hand route the routing delays will dominate the timing differences between the taps and defeat the concept. But then I may have missed something in this thread or not fully understood what I read in the paper. RickArticle: 150405
rickman <gnuarm@gmail.com> wrote: (snip) > Interesting. I am currently working on something similar using an > external programmable delay line. > I looked at the paper, but I'm not sure I understand exactly what you > are trying to measure really. I guess my concern would not be the > issues of timing consistency in the active portions like the carry > chain. Rather my concern would be the routing. There isn't much of a question on routing for the carry chain, especially if you make RPMs out of it. It seems to me that you do have to be careful to get the FF's a constant delay from the chain, but if they are in the same CLB, then I believe it shouldn't be too far off. Well, there is also the clock tree delay, which also has to be consistent enough. That is, more consistent than it does for ordinary designs. Then there is the part in the paper about a bubble, which could occur when the delay is slightly different, such that one tap does come before the previous tap. There is extra logic to fix up that case. > If you look at a > typical timing report, much if not most of a delay is in the routing. > This can be minimized, but that is the issue. If you don't hand place > at least, and better yet, hand route the routing delays will dominate > the timing differences between the taps and defeat the concept. I don't know about the OP, but these are commonly used in PET scanners to determine the time between the arrival of the two gamma rays. The time resolution gives the scanner resolution. > But then I may have missed something in this thread or not fully > understood what I read in the paper. -- glenArticle: 150406
Hello again. The device has not gone trough any in-house irradiation. I do not believe radiation caused this. To me, it seems that I ruined the device by providing input way out of spec. Since I see no problems in newly programmed parts (which differ in encapsulation only), I don´t think I have a problem with my VHDL design. I´ll post an update when this design is burned to an RT-part. Thank you all for your insight. /Karl >I think Karl knows very well that A54SX32A is commercial - not RT - >part. >In any case, A54SX are currently used in many radiation environments. >Just try to google with "A54SX32A radiation". >They are a compromise between robustness against radiation and costs. >When you need thousand of parts it is really costly to purchase RT >version. This is common in application like electronics for particle >physics. I'm used to follow that way with flash A3P commercial (not >RT) family. In this case, the RTA3P's silicon is exactly the same as >the commercial A3P ones. Anyway I don't thinks this applies also to >A54SX vs. RT54SX. Ususally RT OTP flash are tripled (TRM). > >Fully agree with the sentence as A54SX32A are OTP part. > >> as rad tests are not part of device screening only >> qualification (means the design is irradiated, not the delivered >> device). > >but pls be noticed that Karl does not explain the application on >A54SX32A nor it is fully clear if he was really the engineer which >programmed the part. >Could have got it already programmed from someone else ? >In this case, could a radiation test be done ? > >I currently work with A3P commercial parts which was irradiated time >ago and now I'm making measurements on the leakage currents in order >to understand 'end of life' behavior. This is fine with me as I know >what I have in my hands. > >As I wrote, mine was only an hypothesis. The suggestion is to trace >back from where that part comes. >I'm convinced that this is really a far - not probable - possibility >but errors and mistakes could have happened. > >It is up to Karl understand if this could be possible or not. >It depends from where he works, who is his supplier and so on ... > >Anyway I'm sure that many other reasons could explain the part's >behavior. > >Cheers, Fabio > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150407
Am 16.01.2011 23:21, schrieb Brian Drummond: > On Sun, 16 Jan 2011 20:04:04 +0100, Thomas Heller<theller@ctypes.org> 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: > >> 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? > > Here is one paper describing roughly this approach. > > http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/place1.htm > > Linked from > > http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/top.htm > > which may have more information. It seems that these papers describe exactly what I need. Thanks for the links! ThomasArticle: 150408
Am 16.01.2011 23:32, schrieb glen herrmannsfeldt: > Thomas Heller<theller@ctypes.org> wrote: > (snip) > >> 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 > > Sounds prety neat, though, as it says, you need to do the > complete calibration. > > Some years ago I worked with an analog ASIC based TDC that > (as I understand it), it charged a capacitor at constant current > starting at the input pulse, and ending at the clock. Then the > voltage is measured with an ADC. I don't remember now (it was > built into the ASIC, and I didn't have anything to do with that) > how it kept the calibration right. That is, it was an 8 bit ADC, > with full scale at the clock frequency. It supplied the low bits, > a counter at 66MHz supplied the high order bits. Maybe a PLL to > adjust the current. There are, of course, several ways to do high resolution time measurements. > It seems to me that you need FF's with a known time, or at least > constant delay, from the carry chain taps. I don't remember seeing > that in your macros, but I wasn't looking for them, either. I have instantiated the whole delay cell in one CLB. Clock skew is still an issue. > A thought that I didn't see in the Fermilab paper, and maybe won't > work: Use the delay through the whole delay line (or another one > in the same FPGA) to adjust the voltage and/or temperature to keep > the delay constant. Also, maybe you can work with the DCM in the FPGA. Several years ago I implemented 8 16-bits dacs in a small spartanII device as pulse width modulated outputs with external analog low-pass filters; adjusting the power supply voltage in a loop. Worked pretty well, but I want to avoid that approach in the current design. ThomasArticle: 150409
On Jan 16, 7:04=A0pm, Thomas Heller <thel...@ctypes.org> wrote:
> 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?
SHIFT_REGS :for i in 0 to nregs-1 generate
constant rloc_str : string :=3D "X" & integer'image(i) & "Y0";
attribute RLOC of FDE_INST: label is rloc_str;
begin
FDE_INST : FDE port map (
D =3D> cdc_TIG_sync_regs(i),
Q =3D> cdc_TIG_sync_regs(i+1),
CE=3D> '1',
C =3D> clk
);
end generate SHIFT_REGS;
Article: 150410Am 17.01.2011 10:07, schrieb Chris Higgs: > On Jan 16, 7:04 pm, Thomas Heller<thel...@ctypes.org> wrote: >> 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? > > SHIFT_REGS :for i in 0 to nregs-1 generate > constant rloc_str : string := "X"& integer'image(i)& "Y0"; > attribute RLOC of FDE_INST: label is rloc_str; > begin > FDE_INST : FDE port map ( > D => cdc_TIG_sync_regs(i), > Q => cdc_TIG_sync_regs(i+1), > CE=> '1', > C => clk > ); > end generate SHIFT_REGS; Perfect! Thanks, ThomasArticle: 150411
On Jan 17, 12:25=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > (snip) > > > Interesting. =A0I am currently working on something similar using an > > external programmable delay line. > > I looked at the paper, but I'm not sure I understand exactly what you > > are trying to measure really. =A0I guess my concern would not be the > > issues of timing consistency in the active portions like the carry > > chain. =A0Rather my concern would be the routing. =A0 > > There isn't much of a question on routing for the carry chain, > especially if you make RPMs out of it. =A0It seems to me that you > do have to be careful to get the FF's a constant delay from > the chain, but if they are in the same CLB, then I believe it > shouldn't be too far off. =A0Well, there is also the clock tree > delay, which also has to be consistent enough. =A0That is, more > consistent than it does for ordinary designs. Getting the carry to the FF is what it is all about! No, unless the newer architectures are different, you can't run the carry directly into a FF. Actually, as I think about this, I realize that the easiest way to get the carry out is to set up the adder to be adding 1 to -1 with the 1 being the signal you want to time. Then you can capture the sum into a FF at each bit. So that would give you no variation in delay. > Then there is the part in the paper about a bubble, which could > occur when the delay is slightly different, such that one tap does > come before the previous tap. =A0There is extra logic to fix up > that case. =A0 > > > If you look at a > > typical timing report, much if not most of a delay is in the routing. > > This can be minimized, but that is the issue. =A0If you don't hand plac= e > > at least, and better yet, hand route the routing delays will dominate > > the timing differences between the taps and defeat the concept. > > I don't know about the OP, but these are commonly used in PET > scanners to determine the time between the arrival of the two > gamma rays. =A0The time resolution gives the scanner resolution. I am working on a design that has to align an outgoing pulse to an incoming pulse using a delay line with 10 ps resolution. Then it uses a 100 MHz reference to calibrate the delay line and make updates to the delay after the incoming pulse has gone away. Pretty interesting design. I'm only doing the initial part of the FPGA where the 100 MHz "low accuracy" stuff is. The rest of the board is PECL. Still, its pretty interesting. RickArticle: 150412
For the record, here are the answers to my questions ;-)
Am 16.01.2011 20:04, schrieb Thomas Heller:
> 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?
Chris Higgs provided the code which does this:
SHIFT_REGS :for i in 0 to nregs-1 generate
constant rloc_str : string := "X" & integer'image(i) & "Y0";
attribute RLOC of FDE_INST: label is rloc_str;
begin
FDE_INST : FDE port map (
D => cdc_TIG_sync_regs(i),
Q => cdc_TIG_sync_regs(i+1),
CE=> '1',
C => clk
);
end generate SHIFT_REGS;
> 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?
The RLOC_ORIGIN constraint does this.
> 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?
ISE automatically generates HU_SET constraints which puts the RLOCs in
separate groups.
All this is documented here:
http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0155_116.html
RTFM'ly
Thomas
Article: 150413Hi, A spot of blatant advertising, and we'll not trouble you again for another few years, but we thought that we would give the usenet community an opportunity to benefit, as we have over the years from using usenet groups For the month of January, we are making a one-time offer where we have reduced the price of full version of ONEoverT Digital Filter Designer by 90%. The last time we did this was eight years ago. From it's normal cost of 300 GBP, it is now only 30 GBP. You can tell your friends or colleagues, (or don't if you prefer) http://www.tyder.com You will be able to design : FIR filters (windowed and optimal) up to 8192 order IIR filters. Butterworth, Chebyshev (Type I and II) and Elliptic Root and Raised cosine filters up to 8192 order Halfband filters up to 8192 order Differentiators up to 8192 order Hilbert Transformers up to 8192 order Also use FFT facility to analyse data files. You have the ability to link with our VHDL module which you can use to generate all the above filter designs for FPGA or ASIC. Although this is not part of the offer at this time, we will look at each request on a case by case basis. Best Regards Tyder LtdArticle: 150414
On Jan 15, 4:38=A0am, Jonathan Bromley <s...@oxfordbromley.plus.com> wrote: > - Have every operation return a result whose bit width > =A0 is determined solely by the operand widths and the > =A0 operation (VHDL). =A0This has the huge advantage of being > =A0 relatively easy to define and understand, but leads to > =A0 nonsenses in practice; either you get the carry-out from > =A0 an add, in which case it's too wide to put back into > =A0 one of the operand variables, or you throw away the > =A0 carry as numeric_std does. =A0Either way, some users will > =A0 be forced into doing non-obvious things to get the > =A0 results they want. > Jonathan, You seem to attribute one "style" of arithmetic to VHDL, when it has several, distinct, standard "styles". Numeric_std is what you described as "VHDL". There was integer based arithmetic long before that. And more recently, the standard fixed point packages have their own style. Integer is close to MyHDL, but with (very) limited datapath widths (31-32 bits in all existing implementations). The fixed point packages are kind of a hybrid between them. You get the expanded data paths to handle arithmetic precision (unless you do unsigned subtraction!), but unlike integer, you have to manually re- size prior to storage in smaller objects. Then there's also parameterizable floating point too... My point is, this is all possible because of the abilities of the native VHDL language, which itself only defines the integer style (of these we are discussing). Sure, the numeric_std and fixed/floating point packages are part of the IEEE VHDL standard, but they are really nothing more than sactioned user-definable packages of types and functions/operators. I could easily develop and use a package that works like fixed point, but gets unsigned subtraction right (promotion to signed) too, without having to change the language. Or someone much smarter than me could come up with better ways yet. All within the existing VHDL language. AndyArticle: 150415
On Tue, 18 Jan 2011 11:00:13 -0800 (PST), Andy wrote: >On Jan 15, 4:38 am, Jonathan Bromley <s...@oxfordbromley.plus.com> >wrote: >> - 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. >> >You seem to attribute one "style" of arithmetic to VHDL, when it has >several, distinct, standard "styles". Yes, of course you're right. "VHDL" was shorthand for "numeric_std" here, and I should have been clearer. I completely agree about VHDL's wonderful malleability in this respect and I wasn't trying to diss VHDL here at all. Rather, I was trying to use the (perfectly reasonable) behaviour of numeric_std's addition as an example of something that meets some requirements well, but falls badly short for others. We could stay with VHDL and contrast numeric_std's addition with that of the fixed- point package; here the bit-growth on addition preserves mathematical intent but requires you to do some wardances if for any reason you need modulo arithmetic. In other words, it's very hard to come up with a set of behaviour that meets all needs straight out of the box. >Integer [has] (very) limited datapath widths >(31-32 bits in all existing implementations). Yes, and that's horrible - as has been noted here and elsewhere many times. The inability to represent 32-bit unsigned values in a purely-numeric type is painful almost beyond belief. One place where VHDL really is hobbled. Jonathan BromleyArticle: 150416
On Jan 18, 4:57=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com> wrote: > > Rather, I was trying to use the (perfectly reasonable) > behaviour of numeric_std's addition as an example of > something that meets some requirements well, but falls > badly short for others. =A0 So what is your point? Many things are good at one task but not good at another. > We could stay with VHDL and > contrast numeric_std's addition with that of the fixed- > point package; here the bit-growth on addition preserves > mathematical intent but requires you to do some wardances > if for any reason you need modulo arithmetic. =A0In other > words, it's very hard to come up with a set of behaviour > that meets all needs straight out of the box. > You most likely don't expect a screwdriver to be a good hammer so why do you think it reasonable to state how using the wrong package (i.e. 'tool') makes it difficult or awkward to meet certain requirements? Use the best tool you can for the particular problem...grumble only if it is still awkward and clumsy for that task...but only if the limitations of some other tool (in this case the VHDL LRM) inhibit you from creating a better tool more suited to the task. - Use the right tool for the right job - Be satisified when you are able to create a new and useful tool that is applicable for a certain class of problems. > >Integer [has] (very) limited datapath widths > >(31-32 bits in all existing implementations). > > Yes, and that's horrible - as has been noted here and > elsewhere many times. =A0The inability to represent 32-bit > unsigned values in a purely-numeric type is painful almost > beyond belief. =A0One place where VHDL really is hobbled. > The VHDL group is currently begining on a new revision...perhaps you'll contribute your solutions to that group where it could have some effect. That would be the proper forum to possibly effect change. Kevin JenningsArticle: 150417
On 12/01/2011 00:24, glen herrmannsfeldt wrote: > pes<dontspamme@thanks.com> wrote: > >> I would like to implement an algorithm on a deconvolution for a Spartan6. >> Do you know some references of implementation or algorithm that me help >> in my task? > > My favorite reference on deconvolution is "Deconvolution of > Images and Spectra" by Jansson. (That is, the second edition.) > > I just noticed that there is a "soon to be released" paperback > version from bn.com for $10.97 (preorder price). The hardcover > version was about $100 when I bought mine in 1997 (when it was new). > > It seems that a used one is now available for $350. > > Note specifically that the book is about non-linear deconvolution. > Even if you are planning for linear deconvolution, it is a good > reference to have. > > -- glen Thank you I will take a look over there.Article: 150418
rickman <gnuarm@gmail.com> writes: > 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? I don't know what to recommend, since I haven't used Verilog much since 2002. I did buy Botros' book recently since it's so cheap and includes a CD too with code examples and figures from the book. But I mostly need a VHDL book and this one seems a little shallow so I find myself relying on Ashenden's VHDL book mostly. I do beliece Botros' book is the only book in print that covers both VHDL and Verilog. When I was learning Verilog in the mid-1990s, I think I used Cadence's excellent manuals for the old Verilog-XL and experienced colleagues.Article: 150419
On Jan 19, 5:49=A0am, Anssi Saari <a...@sci.fi> wrote: > rickman <gnu...@gmail.com> writes: > > 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 t= o > > 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? > > I don't know what to recommend, since I haven't used Verilog much > since 2002. I did buy Botros' book recently since it's so cheap and > includes a CD too with code examples and figures from the book. But I > mostly need a VHDL book and this one seems a little shallow so I find > myself relying on Ashenden's VHDL book mostly. I do beliece Botros' > book is the only book in print that covers both VHDL and Verilog. > > When I was learning Verilog in the mid-1990s, I think I used Cadence's > excellent manuals for the old Verilog-XL and experienced colleagues. I'm curious, why are you using VHDL more now? Is this a job requirement or do you prefer VHDL? Was there something about Verilog you didn't like? As I am learning Verilog, I am finding that I had become pretty used to VHDL and I had a certain level of comfort knowing that if I made a dumb mistake, the tool would most likely let me know. When I go through the warning list with Verilog I see a number of things that could easily trip me up. I guess I'm nervous that I am going to be bitten by one of these at some point. I guess I'll keep checking the warnings. RickArticle: 150420
On Jan 19, 11:19=A0am, rickman <gnu...@gmail.com> wrote: > On Jan 19, 5:49=A0am, Anssi Saari <a...@sci.fi> wrote: > > > > > rickman <gnu...@gmail.com> writes: > > > 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. =A0T= he > > > 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 th= e > > > books you like? > > > I don't know what to recommend, since I haven't used Verilog much > > since 2002. I did buy Botros' book recently since it's so cheap and > > includes a CD too with code examples and figures from the book. But I > > mostly need a VHDL book and this one seems a little shallow so I find > > myself relying on Ashenden's VHDL book mostly. I do beliece Botros' > > book is the only book in print that covers both VHDL and Verilog. > > > When I was learning Verilog in the mid-1990s, I think I used Cadence's > > excellent manuals for the old Verilog-XL and experienced colleagues. > > I'm curious, why are you using VHDL more now? =A0Is this a job > requirement or do you prefer VHDL? =A0Was there something about Verilog > you didn't like? > > As I am learning Verilog, I am finding that I had become pretty used > to VHDL and I had a certain level of comfort knowing that if I made a > dumb mistake, the tool would most likely let me know. =A0When I go > through the warning list with Verilog I see a number of things that > could easily trip me up. =A0I guess I'm nervous that I am going to be > bitten by one of these at some point. =A0I guess I'll keep checking the > warnings. > > Rick One of the big "biters" in Verilog is the ability to declare a net implicitly. This often covers up a mistake in spelling. There is even no warning for implicitly declared nets unless they happen to cause a size mismatch at a module port (this would be an error in VHDL). Verilog 2001 has added the 'default_nettype directive which allows you to override this behavior. I generally do this at the top of each module: `default_nettype none module foo . . . And then this at the bottom: endmodule `default_nettype wire Bringing the default back. Note that as long as you only write your own code this bit at the end would make no difference, but as soon as you add some IP from another source (Xilinx comes to mind) you can end up with piles of errors when they use implicitly declared nets. There are some things about Verilog that I think make it much more human friendly like not requiring constants to be sized. I go batty reading VHDL case statements with all the cases listed in binary. However, this can again show some lack of error coverage because there is no check to see if the constant will even fit into the size required by the operand. For example: reg [3:0] foo; always @ (posedge clk) foo <=3D 25; Obviously you can't fit 25 into a 4-bit register, but this won't even cause a warning, it just blithely takes the low 4 bits of the value and stuffs it into foo. -- GaborArticle: 150421
On Jan 19, 2:12=A0pm, Gabor <ga...@alacron.com> wrote: > On Jan 19, 11:19=A0am, rickman <gnu...@gmail.com> wrote: > > > As I am learning Verilog, I am finding that I had become pretty used > > to VHDL and I had a certain level of comfort knowing that if I made a > > dumb mistake, the tool would most likely let me know. =A0When I go > > through the warning list with Verilog I see a number of things that > > could easily trip me up. =A0I guess I'm nervous that I am going to be > > bitten by one of these at some point. =A0I guess I'll keep checking the > > warnings. > > One of the big "biters" in Verilog is the ability to declare a net > implicitly. > This often covers up a mistake in spelling. =A0There is even no warning > for implicitly declared nets unless they happen to cause a size > mismatch > at a module port (this would be an error in VHDL). =A0Verilog 2001 has > added the 'default_nettype directive which allows you to override this > behavior. =A0I generally do this at the top of each module: > > `default_nettype none > > module foo > . . . > And then this at the bottom: > > endmodule > > `default_nettype wire > > Bringing the default back. =A0Note that as long as you only write your > own > code this bit at the end would make no difference, but as soon as you > add some IP from another source (Xilinx comes to mind) you can end > up with piles of errors when they use implicitly declared nets. > > There are some things about Verilog that I think make it much more > human friendly like not requiring constants to be sized. =A0I go batty > reading VHDL case statements with all the cases listed in binary. > However, this can again show some lack of error coverage because > there is no check to see if the constant will even fit into the size > required by the operand. =A0For example: > > reg [3:0] foo; > > always @ (posedge clk) > =A0 foo <=3D 25; > > Obviously you can't fit 25 into a 4-bit register, but this won't even > cause > a warning, it just blithely takes the low 4 bits of the value and > stuffs it > into foo. And that's the sticky wicket, isn't it? Getting the tool to understand what you want without having to tell it every excruciating detail. VHDL requires you to tell it enough that it doesn't need to assume and Verilog lets you get by with what a person might need to be told, but if you aren't on the same page with the tool, you won't get what you expected. I've been wanting to learn Verilog well enough that I can make a fully educated opinion about which is better but just hadn't found the time for it. I probably still wouldn't be learning it, but I have some work that requires it. So I'm trying to take the time to learn it properly rather than just getting by with code that seems to work. Thanks for the info. RickArticle: 150422
Hi. There are a such thing as Great Internet Mersenne Prime Search (GIMPS): "The Great Internet Mersenne Prime Search (GIMPS) is a collaborative project of volunteers who use freely available computer software to search for Mersenne prime numbers." "To perform its testing, the project relies primarily on =C9douard Lucas and Derrick Henry Lehmer's primality test,[3] an algorithm that is both specialized to testing Mersenne primes and particularly efficient on binary computer architectures." http://en.wikipedia.org/wiki/Great_Internet_Mersenne_Prime_Search There are another number primality tests exists, so the question is, is there can be such primality test which is suitable for FPGA in such way, when it will work much more effectively than =C9douard Lucas and Derrick Henry Lehmer's primality test running on generic computer? P.S.: https://www.eff.org/awards/coopArticle: 150423
On 20 Jan., 08:10, Dennis Yurichev <dennis.yuric...@gmail.com> wrote: > Hi. > > There are a such thing as Great Internet Mersenne Prime Search > (GIMPS): > > "The Great Internet Mersenne Prime Search (GIMPS) is a collaborative > project of volunteers who use freely available computer software to > search for Mersenne prime numbers." > > "To perform its testing, the project relies primarily on =C9douard Lucas > and Derrick Henry Lehmer's primality test,[3] an algorithm that is > both specialized to testing Mersenne primes and particularly efficient > on binary computer architectures." > > http://en.wikipedia.org/wiki/Great_Internet_Mersenne_Prime_Search > > There are another number primality tests exists, so the question is, > is there can be such primality test which is suitable for FPGA in such > way, when it will work much more effectively than =C9douard Lucas and > Derrick Henry Lehmer's primality test running on generic computer? > > P.S.:https://www.eff.org/awards/coop Hi, some thoughts about the problem. Actual numbers under test have more than 12 million decimal digits. It would be interesting to know if the algorithm can work on these digits in a streaming way, or if it needs random access. In the second case the performance gain may be neglectible. Another interesting point would be, if such an algorithm could perform better when working on a true binary representation of the number under test. This would probably increase the number of binary digits, but hopefully increase the performance of the algorithm. Also, the steps of generating/converting the number could be separated from the algorithm itself. If the algorithm can work in parallel (that is, multiple instances can work on the same number under test) it would further benefit from a hardware implementation. So, the first useful thing to do would be to take a close look at the algorithms for testing the prime nature of a given number. Have a nice synthesis EilertArticle: 150424
Hi, I've googled about a bit, but not found the perfect answer yet. Does anyone have any suggestions for reading material (paper or web), that would serve as an introductory overview of FPGAs for non-technical managers? Something that gives a rough idea of what typically can and cannot be achieved in hardware, and a sense of the difficulties and effort required to do so. Thats probably a lot to ask, but if you know of any good introductions, I would appreciate a link. Thanks for your help. Rupert
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