Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 150400

Article: 150400
Subject: Re: Location constraints questions
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 16 Jan 2011 22:21:01 +0000
Links: << >>  << T >>  << A >>
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.

- Brian

Article: 150401
Subject: Re: Location constraints questions
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 16 Jan 2011 22:32:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen

Article: 150402
Subject: Re: Location constraints questions
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 16 Jan 2011 23:23:06 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Location constraints questions
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 16 Jan 2011 23:56:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.  

-- glen

Article: 150404
Subject: Re: Location constraints questions
From: rickman <gnuarm@gmail.com>
Date: Sun, 16 Jan 2011 19:02:05 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 150405
Subject: Re: Location constraints questions
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 17 Jan 2011 05:25:57 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.

-- glen

Article: 150406
Subject: Re: Low slewrate, abnormal current consumption.
From: "karl.bengtsson" <karl.bengtsson@n_o_s_p_a_m.n_o_s_p_a_m.norspace.no>
Date: Mon, 17 Jan 2011 01:38:56 -0600
Links: << >>  << T >>  << A >>
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.com

Article: 150407
Subject: Re: Location constraints questions
From: Thomas Heller <theller@ctypes.org>
Date: Mon, 17 Jan 2011 08:59:01 +0100
Links: << >>  << T >>  << A >>
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!

Thomas

Article: 150408
Subject: Re: Location constraints questions
From: Thomas Heller <theller@ctypes.org>
Date: Mon, 17 Jan 2011 09:06:34 +0100
Links: << >>  << T >>  << A >>
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.

Thomas

Article: 150409
Subject: Re: Location constraints questions
From: Chris Higgs <chiggs.99@gmail.com>
Date: Mon, 17 Jan 2011 01:07:54 -0800 (PST)
Links: << >>  << T >>  << A >>
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: 150410
Subject: Re: Location constraints questions
From: Thomas Heller <theller@ctypes.org>
Date: Mon, 17 Jan 2011 11:41:55 +0100
Links: << >>  << T >>  << A >>
Am 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,
Thomas

Article: 150411
Subject: Re: Location constraints questions
From: rickman <gnuarm@gmail.com>
Date: Mon, 17 Jan 2011 09:04:35 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 150412
Subject: Re: Location constraints questions
From: Thomas Heller <theller@ctypes.org>
Date: Tue, 18 Jan 2011 09:00:08 +0100
Links: << >>  << T >>  << A >>
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: 150413
Subject: ANN: One time offer...ONEoverT Digital Filter Designer..reduced by
From: Bob <stenasc@yahoo.com>
Date: Tue, 18 Jan 2011 01:28:19 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

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 Ltd

Article: 150414
Subject: Re: Verilog Book for VHDL Users
From: Andy <jonesandy@comcast.net>
Date: Tue, 18 Jan 2011 11:00:13 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Andy

Article: 150415
Subject: Re: Verilog Book for VHDL Users
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Tue, 18 Jan 2011 21:57:45 +0000
Links: << >>  << T >>  << A >>
On Tue, 18 Jan 2011 11:00:13 -0800 (PST), Andy wrote:

>On Jan 15, 4:38am, 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 Bromley

Article: 150416
Subject: Re: Verilog Book for VHDL Users
From: KJ <kkjennings@sbcglobal.net>
Date: Tue, 18 Jan 2011 20:04:36 -0800 (PST)
Links: << >>  << T >>  << A >>
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 Jennings

Article: 150417
Subject: Re: deconvolution
From: pes <dontspamme@thanks.com>
Date: Wed, 19 Jan 2011 09:30:35 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Verilog Book for VHDL Users
From: Anssi Saari <as@sci.fi>
Date: Wed, 19 Jan 2011 12:49:24 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: Verilog Book for VHDL Users
From: rickman <gnuarm@gmail.com>
Date: Wed, 19 Jan 2011 08:19:07 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 150420
Subject: Re: Verilog Book for VHDL Users
From: Gabor <gabor@alacron.com>
Date: Wed, 19 Jan 2011 11:12:06 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

-- Gabor

Article: 150421
Subject: Re: Verilog Book for VHDL Users
From: rickman <gnuarm@gmail.com>
Date: Wed, 19 Jan 2011 11:55:58 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 150422
Subject: Prime number testing on FPGA
From: Dennis Yurichev <dennis.yurichev@gmail.com>
Date: Wed, 19 Jan 2011 23:10:51 -0800 (PST)
Links: << >>  << T >>  << A >>
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

Article: 150423
Subject: Re: Prime number testing on FPGA
From: backhus <goouse99@googlemail.com>
Date: Thu, 20 Jan 2011 01:35:27 -0800 (PST)
Links: << >>  << T >>  << A >>
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
  Eilert

Article: 150424
Subject: Overview for non-technicals.
From: "rupertlssmith@googlemail.com" <rupertlssmith@googlemail.com>
Date: Thu, 20 Jan 2011 02:11:35 -0800 (PST)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search