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 108125

Article: 108125
Subject: Re: FIFO with EBR
From: "Gabor" <gabor@alacron.com>
Date: 5 Sep 2006 11:58:50 -0700
Links: << >>  << T >>  << A >>

Mike Treseler wrote:
> ALuPin@web.de wrote:
>
> > I have tried to synthesize the synchronous fifo example "FIFO.vhd"
> > from Ben Cohen's book "Real Chip Design and Verification Using Verilog
> > and VHDL" on a Lattice EC15 (Synplicity compiler)
> > For the FIFO registers declaration I add the following
> > attribute :
> >
> > attribute syn_ramstyle                  : string;
> > attribute syn_ramstyle OF FIFO_r : SIGNAL IS "block_ram";
> >
> > And yet the synthesis results show that no Embedded RAM
> > blocks are used.
>
> If the target fpga has block ram, and if you
> use the recommended code template, no
> attribute hints are required.
>
> > Is the used attribute not appropriate or is Synplify not able
> > to implement the registers as EBR in that hardware description?
>
> Attributes and commented directives
> are vendor specified, and only work
> for tools that recognize them.
>
>
>             -- Mike Treseler

Also make sure the FIFO code can be made from block RAM.  In
Lattice, like Xilinx, the block RAM's have registered outputs, so
code that implements a combinatorial read function cannot be
synthesized using EBR.


Article: 108126
Subject: Re: Serial I/O Question
From: "motty" <mottoblatto@yahoo.com>
Date: 5 Sep 2006 12:22:03 -0700
Links: << >>  << T >>  << A >>

Thanks Antti!

Unfortunately, the phase is not guarenteed over multiple frames.  The
interface needs to be able to sync each frame transmission.  It's is
definitely going to be tricky.

The SERDES I was referring to was in the ILOGIC stuff.  I haven't even
looked into using the MGT's, though that may be a possibility.

Oh well......


Article: 108127
Subject: Re: FPGA multiplier
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 05 Sep 2006 20:03:27 GMT
Links: << >>  << T >>  << A >>
Austin Lesea <austin@xilinx.com> wrote:

>Tejo,
>
>http://direct.xilinx.com/bvdocs/userguides/ug073.pdf
>
>Yes, the 18X18 multiplier/accumulator is a hardened block, so that
>performing this function results in from 8 to 20 times less power than
>performing this function would if it was done in the logic of the FPGA
>(luts, dff, interconnect, etc.)
>
>The above guide details use of the V4 for "extreme" DSP uses.
>
>FPGAs are useful for tasks that DSP processors are too slow for,
>otherwise, DSP processors are generally far easier and better suited for
>DSP.  For example, a video conference processor, where multiple streams
>must be encoded, decoded, combined, along with all audio processing is
>one such task where a FPGA would excel for both cost, power, and
>performance.

I doubt about cost and preformance. Developing such a device would
probably take so much time that an ASIC is just as cost effective and
uses even less power. An older PC is already capable of doing these
functions with a development time that can be expressed in days, not
years.

Even when dealing with loads of videostreams at high resolutions it is
more cost effective, reliable and flexible to use PCs on a fast
network to do the processing rather than building a custom FPGA/ASIC
solution.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 108128
Subject: Re: Serial I/O Question
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 05 Sep 2006 20:17:20 GMT
Links: << >>  << T >>  << A >>
300 MB/s may be a little slow, but you might find good info in

http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf

The method I'm using (derived before finding this XAPP) in the Spartan3E 
family has a phase locked clock and a long training period to recover 3 
channels of 600 Mb/s data each.  I don't believe (I'm not sure) the method 
in XAPP671 needs much of a training period.  While the 300 MB/s is easily 
half the speed covered by that app note, you might find good ideas there.
_____

"motty" <mottoblatto@yahoo.com> wrote in message 
news:1157480088.467287.234360@d34g2000cwd.googlegroups.com...
>I need to recover data from a serial LVDS I/O stream running at over
> 300 MHz.  A reference 26 MHz clock is provided by the data source.  So
> that clock needs to be bumped up to the data rate.  The fast data is
> NOT phase aligned with the reference (or derived) clock.  There is a
> 16-bit sync pattern at the start of every 'frame' of data.  There is
> guarenteed to be at least one bit of '0' before the sync pattern starts
> - between frames or from reset.  It starts with a '1'.  So a zero to
> one tansition will start the sync pattern if the 'logic' is 'searching'
> for the sync.
>
> I have implemented some hardware that will work by using 4 phases of
> the fast clock.  And I basically built a serial-to-parallel logic block
> that takes the data and deserializes it.  The sync is searched for and
> detected.  Once detected, the data is passed from the best phased clock
> domain.  This all works fine and well at 100 MHz.  I knew I would never
> get it up to the speed I need (Virtex4 LX25 -10) using the fabric.  So
> I've looked in to using the SERDES IO technology.  I've read the user
> guide and looked at some applications notes, but haven't found anything
> that really matches what I need.  The logic that the app notes
> implement either rely on bit-syncronization techniques or a steady
> training pattern over a 'long' time.  Those take too long to complete.
> I need to decide what phase of the clock to use (to ensure good data
> capture over a given frame) and pass that data on in less than the
> 16-bit sync pattern.  I know there are many possible solutions, but I
> was just posting this while I mess around with this problem.  Anyone
> have any ideas?
>
> Thanks!
> 



Article: 108129
Subject: Re: FPGA multiplier
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 05 Sep 2006 13:40:48 -0700
Links: << >>  << T >>  << A >>
Nico,

We (Peter and I) have decided to avoid any marketing discussions.

On technical subjects, at least I can (usually) post something useful.

You decide when, where, and how to use Xilinx FPGAs.

I am happy if you use them at all, for whatever you find profitable.

The website speaks for itself:  there are lots of customer testimonials
for those who wish to read them.  You decide.

Perhaps others can post why they use our FPGAs for extreme DSP?

Austin



Nico Coesel wrote:
> Austin Lesea <austin@xilinx.com> wrote:
> 
>> Tejo,
>>
>> http://direct.xilinx.com/bvdocs/userguides/ug073.pdf
>>
>> Yes, the 18X18 multiplier/accumulator is a hardened block, so that
>> performing this function results in from 8 to 20 times less power than
>> performing this function would if it was done in the logic of the FPGA
>> (luts, dff, interconnect, etc.)
>>
>> The above guide details use of the V4 for "extreme" DSP uses.
>>
>> FPGAs are useful for tasks that DSP processors are too slow for,
>> otherwise, DSP processors are generally far easier and better suited for
>> DSP.  For example, a video conference processor, where multiple streams
>> must be encoded, decoded, combined, along with all audio processing is
>> one such task where a FPGA would excel for both cost, power, and
>> performance.
> 
> I doubt about cost and preformance. Developing such a device would
> probably take so much time that an ASIC is just as cost effective and
> uses even less power. An older PC is already capable of doing these
> functions with a development time that can be expressed in days, not
> years.
> 
> Even when dealing with loads of videostreams at high resolutions it is
> more cost effective, reliable and flexible to use PCs on a fast
> network to do the processing rather than building a custom FPGA/ASIC
> solution.
> 

Article: 108130
Subject: Re: FPGA multiplier
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: 5 Sep 2006 23:20:57 +0200
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
> Even when dealing with loads of videostreams at high resolutions it is
> more cost effective, reliable and flexible to use PCs on a fast
> network to do the processing rather than building a custom FPGA/ASIC
> solution.
> 

Probably there are other constraints. Do you need 1,000 of these?
Is it a mass market product? Does it need to fit in a rack? In a
unit the size of a pack of cigarettes?

Getting something working in a lab in just any old manner, perhaps
for getting funding, is one thing. Getting to a fieldable solution...

There is no way one can make a blanket statement about the best
solution without knowing all the requirements.

In my case I worked on a project that had to encode live NTSC video
to mpeg-2 I frames with a minimum of latency. The solution ended
up being DSP based, blackfin DSP's, 4 video/audio inputs on a PCI
card. It was a big project. In the end we were limited by the performance
of the DSP's. The frame size ended up being 352x240 at 60 hz. There
was just no way we could ever do 720x240 -- had to downsample in X.

Now if we'd opted for an FPGA, if it was big enough we'd have had
lots of options to improve performance. We could have licensed
some existing IP, modified it to suit. It would have been a bigger
unknown since none of us had direct FPGA experience, but we did
have low level programming experience. Going an FPGA route might
have been a better investment in the long run...

Use the right technology/solution for the task at hand. No one size
fits all.

-Dave


-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108131
Subject: Re: FPGA multiplier
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: 5 Sep 2006 23:32:48 +0200
Links: << >>  << T >>  << A >>
David Ashley wrote:
> Now if we'd opted for an FPGA, if it was big enough we'd have had
> lots of options to improve performance. We could have licensed
> some existing IP, modified it to suit. It would have been a bigger
> unknown since none of us had direct FPGA experience, but we did
> have low level programming experience. Going an FPGA route might
> have been a better investment in the long run...

One more thing occured to me. With the Analog Devices blackfin DSP
approach we found out the hard way memory bandwidth was a severely
limiting factor. The DSP had some small amount of on chip memory
that ran at the CORE clock frequency. The SYSTEM clock was a fraction
of that, say 1/5th or 1/6th. Accessing external SDRAM took something
like 6 SCLOCKS, which translates to 36 CORE clocks. Thats a *long*
time in DSP space. The SDRAM controller never did burst accesses, as I
recall.

What that means is you can't effectively do anything unless you use
the on chip fast memory, which operates at the CORE clock frequency
(600 mhz to 750 mhz for example). But that was a limited resource.
And there was no way to improve the SDRAM controller, that was part
of the chip. So the resolution *couldn't* improve, we didn't have memory
for it, and no amount of optimization would work.

With an FPGA, on the other hand, one could have modified the external
memory controller to burst out a whole 64 byte chunk of memory, or
burst one into a BRAM. Then operate in the BRAM, then write it back
out. Doing burst accesses would really speed things up, and the memory
IO could go in in parallel with other processing. In short there would be
almost unlimited ability to optimize, as needed.

With the fixed-cpu DSP approach, we found out the limits the hard way.
Then we had to reduce our expectations. In the end it was OK, but it
might have been a disaster.

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108132
Subject: Virtex4 FPGA minimum power
From: "pomerado@hotmail.com" <pomerado@hotmail.com>
Date: 5 Sep 2006 15:27:38 -0700
Links: << >>  << T >>  << A >>
A Virtex4 FPGA is mounted on a board which has a sleep mode to conserve
battery power during periods of inactivity.  Is it only necessary to
keep the VCCaux power on to maintain the configuration memory, and all
the other power inputs can be turned off?


Article: 108133
Subject: Re: Virtex4 FPGA minimum power
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 05 Sep 2006 15:44:55 -0700
Links: << >>  << T >>  << A >>
Pomerado,

The Vcc_config must stay powered, the Vcc_aux must stay powered, and the
Vccint must stay powered.

If any of these drops below their power on reset thresholds, the device
erases all memory before trying to configure.

Vcco_config POR trip is ~ 0.5 to 0.75V
Vcc_aux POR trip is ~1.3 to 1.8V
Vccint POR trip is ~0.5 to 0.75V

I recommend that you may lower each supply only to what is specified in
the recommended operating conditions table of the data sheet, and no less.

This, of course, after you place the design in a state where all clocks
are disabled, IOs tristate, and just waiting for a signal on an IOB pin
to wake up, and start processing from where it left off.

Table 4 is where you will find the min currents:
http://direct.xilinx.com/bvdocs/publications/ds302.pdf

Austin

pomerado@hotmail.com wrote:
> A Virtex4 FPGA is mounted on a board which has a sleep mode to conserve
> battery power during periods of inactivity.  Is it only necessary to
> keep the VCCaux power on to maintain the configuration memory, and all
> the other power inputs can be turned off?
> 

Article: 108134
Subject: Re: Serial I/O Question
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Tue, 05 Sep 2006 18:45:31 -0400
Links: << >>  << T >>  << A >>
motty wrote:
> Thanks Antti!
> 
> Unfortunately, the phase is not guarenteed over multiple frames.  The
> interface needs to be able to sync each frame transmission.  It's is
> definitely going to be tricky.
> 
> The SERDES I was referring to was in the ILOGIC stuff.  I haven't even
> looked into using the MGT's, though that may be a possibility.
> 
> Oh well......
> 

MGTs on V4-LX parts? You may want to revisit the datasheet before 
getting your hopes up: only the FX V4 variant has MGTs. Unless you can 
still ECO the part and live with the price delta between the two parts, 
this avenue is busted.

-- 
Daniel Sauvageau
moc.xortam@egavuasd
Matrox Graphics Inc.
1155 St-Regis, Dorval, Qc, Canada
514-822-6000

Article: 108135
Subject: Re: Please help me with (insert task here)
From: "tlbs101" <tlbs101@excite.com>
Date: 5 Sep 2006 15:55:12 -0700
Links: << >>  << T >>  << A >>

CBFalconer wrote:

> I used to install a roughly 68 ohm 1/2 watt carbon resistor across
> the AC mains (110 volt) after the power switch.  This was usually
> done at lunch time, while someone else was preparing for his
> initial smoke test on a new instrument (back in the days of
> tubes).  The result was a satisfactory grrr-bang and smoke.  Modern
> resistors don't work as well, they just fizzle.
>

Try 1/4 watt 1000 Ohm metal film resistors, they glow red, then make a
decent, "pop".

~100 uF ~10V radial aluminum electrolytics make great confetti
generators, when plugged into standard 120V power outlets.

Kids, don't try this at home.

Ah, memories!

Tom


Article: 108136
Subject: Re: Open-source CableServer for Impact (no more need for Jungo driver on Linux)
From: Daniel O'Connor <darius@dons.net.au>
Date: Wed, 06 Sep 2006 08:32:58 +0930
Links: << >>  << T >>  << A >>
zcsizmadia@gmail.com wrote:
> I've reversed engineer the CableServer communication with Impact and
> written from scratch a brand new CableServer. Currently only Parallel
> III cable is implemented, but new cables can be added very easily. I
> will post the project on sourceforge.net next week.

Nice! Good work.

> Antti wasn't really helpful to come up with a name for the project, so
> it will be called "cblsrv" :)

If it doesn't crash like the Xilinx one you could call it "AbleServe" :)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

Article: 108137
Subject: Re: Please help me with (insert task here)
From: Jim Stewart <jstewart@jkmicro.com>
Date: Tue, 05 Sep 2006 16:48:20 -0700
Links: << >>  << T >>  << A >>
tlbs101 wrote:
> CBFalconer wrote:
> 
> 
>>I used to install a roughly 68 ohm 1/2 watt carbon resistor across
>>the AC mains (110 volt) after the power switch.  This was usually
>>done at lunch time, while someone else was preparing for his
>>initial smoke test on a new instrument (back in the days of
>>tubes).  The result was a satisfactory grrr-bang and smoke.  Modern
>>resistors don't work as well, they just fizzle.
>>
> 
> 
> Try 1/4 watt 1000 Ohm metal film resistors, they glow red, then make a
> decent, "pop".
> 
> ~100 uF ~10V radial aluminum electrolytics make great confetti
> generators, when plugged into standard 120V power outlets.

An SCR, placed across the terminals of a decent
sized gelcell will give a very rewarding blue
flash followed by an orange fireball after it's
been turned on.


Article: 108138
Subject: Re: Forth-CPU design
From: Jerry Avins <jya@ieee.org>
Date: Tue, 05 Sep 2006 20:32:57 -0400
Links: << >>  << T >>  << A >>
jacko wrote:
> hi
> 
> just wondering if grey code (1 bit change) addressed stack memory might
> be useful for cutting down carry chain logic for pre-post dec/inc
> addressing??

Gray codes are useful for reading data, but they need extra hardware for 
counting and addressing. (If course, Gray-code addressing is no 
different from any other scrambling of the address lines too a memory 
chip. Page accesses aside, the memory doesn't care. It can make a ROM 
difficult to reverse engineer, particularly id the data lines are 
scrambled too.)

Jerry
-- 
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

Article: 108139
Subject: Re: Serial I/O Question
From: "motty" <mottoblatto@yahoo.com>
Date: 5 Sep 2006 17:47:43 -0700
Links: << >>  << T >>  << A >>

Daniel S. wrote:
> motty wrote:
> > Thanks Antti!
> >
> > Unfortunately, the phase is not guarenteed over multiple frames.  The
> > interface needs to be able to sync each frame transmission.  It's is
> > definitely going to be tricky.
> >
> > The SERDES I was referring to was in the ILOGIC stuff.  I haven't even
> > looked into using the MGT's, though that may be a possibility.
> >
> > Oh well......
> >
>
> MGTs on V4-LX parts? You may want to revisit the datasheet before
> getting your hopes up: only the FX V4 variant has MGTs. Unless you can
> still ECO the part and live with the price delta between the two parts,
> this avenue is busted.
>
> --
> Daniel Sauvageau
> moc.xortam@egavuasd
> Matrox Graphics Inc.
> 1155 St-Regis, Dorval, Qc, Canada
> 514-822-6000

Yeah, I am not well versed in the V4 parts, but I quickly found out the
LX doesn't have MGT's. : )

We will eventually be using a V5 part, so I need to look into those
details.  I don't know if the MGT would work anyway.  It lists a
minimum frequency of ~600 Mbps.  I don't know if that is a hard line or
not.  But right now I am just looking in to what methods are available
and trying different approaches.


Article: 108140
Subject: Re: Serial I/O Question
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 5 Sep 2006 19:25:32 -0700
Links: << >>  << T >>  << A >>
I might add that the two authors of XAPP671, Catalin Baetoniu and Tze
Yi Yeoh, are experienced and very much respected within Xilinx.
Peter Alfke
===================
John_H wrote:
> 300 MB/s may be a little slow, but you might find good info in
>
> http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf
>
> The method I'm using (derived before finding this XAPP) in the Spartan3E
> family has a phase locked clock and a long training period to recover 3
> channels of 600 Mb/s data each.  I don't believe (I'm not sure) the method
> in XAPP671 needs much of a training period.  While the 300 MB/s is easily
> half the speed covered by that app note, you might find good ideas there.
> _____
>
> "motty" <mottoblatto@yahoo.com> wrote in message
> news:1157480088.467287.234360@d34g2000cwd.googlegroups.com...
> >I need to recover data from a serial LVDS I/O stream running at over
> > 300 MHz.  A reference 26 MHz clock is provided by the data source.  So
> > that clock needs to be bumped up to the data rate.  The fast data is
> > NOT phase aligned with the reference (or derived) clock.  There is a
> > 16-bit sync pattern at the start of every 'frame' of data.  There is
> > guarenteed to be at least one bit of '0' before the sync pattern starts
> > - between frames or from reset.  It starts with a '1'.  So a zero to
> > one tansition will start the sync pattern if the 'logic' is 'searching'
> > for the sync.
> >
> > I have implemented some hardware that will work by using 4 phases of
> > the fast clock.  And I basically built a serial-to-parallel logic block
> > that takes the data and deserializes it.  The sync is searched for and
> > detected.  Once detected, the data is passed from the best phased clock
> > domain.  This all works fine and well at 100 MHz.  I knew I would never
> > get it up to the speed I need (Virtex4 LX25 -10) using the fabric.  So
> > I've looked in to using the SERDES IO technology.  I've read the user
> > guide and looked at some applications notes, but haven't found anything
> > that really matches what I need.  The logic that the app notes
> > implement either rely on bit-syncronization techniques or a steady
> > training pattern over a 'long' time.  Those take too long to complete.
> > I need to decide what phase of the clock to use (to ensure good data
> > capture over a given frame) and pass that data on in less than the
> > 16-bit sync pattern.  I know there are many possible solutions, but I
> > was just posting this while I mess around with this problem.  Anyone
> > have any ideas?
> >
> > Thanks!
> >


Article: 108141
Subject: Re: fastest FPGA
From: "rickman" <gnuarm@gmail.com>
Date: 5 Sep 2006 19:29:39 -0700
Links: << >>  << T >>  << A >>
John_H wrote:
> Moving pointers would require an addressable load and an addressable read -
> what's available with dual-ports.  A fixed entry with single addressable
> output mux gives everything needed for an addressable serial-in shift
> register without the need for extra bits.  Maintaining the in pointer and
> calculating the out pointer from the "I want the 5th bit" control to the
> output mux is a sincere amount of logic above and beyond the normal LUT
> structure.  The SRL's output MUX is the same as used for providing the LUT
> output in normal operation requiring no additional logic beyond the shift
> through the 16 memory cells.
>
> There are many applications where a FIFO structure is best handled with
> separate in/out pointers, particularly when changing between time domains.
> The SRLs ar restricted to the same time domain for the input and output but
> don't need the extra pointers.  As a FIFO, the SRLs have a slightly more
> complicated single pointer (adds and subtracts for write and read,
> respectively) but ends up more compact in the end.

I gave this a bit more thought and realized that there is already a lot
of circuitry in the LUT.  It has the output mux (read decode) and the
write address decode and the LUT RAM bits are already in a shift
register for loading configuration data.  So the SRL is essentialy
free.  To use a moving pointer two 4 bit counters would have to be
added, so I am sure they would not want to do it this way.

Can you use the SRL as a FIFO?  I was not aware that you could change
the length.  I thought that was a configuration setting.  If they are
doing that the only extra for the moving pointers would be the 4 bit
write address counter.


Article: 108142
Subject: Re: fastest FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 5 Sep 2006 19:45:57 -0700
Links: << >>  << T >>  << A >>
small corrections inserted:
rickman wrote:
> I gave this a bit more thought and realized that there is already a lot
> of circuitry in the LUT.  It has the output mux (read decode) and the
> write address decode and the LUT RAM bits are already in a shift
> register for loading configuration data.
Not really, there is a common loading mechanism, but that has to serve
the whole chip.
The "prior to V5" SRL16 uses the age-old trick of differentiating the
clock and putting a low-pass filter between the latches. Like we used
to do in the 'fifties and 'sixties, when transistors were expensive.
Since this does not scale well at 65 nm and below, V5 went back to the
"proper 2-latches per bit, master/slave" method.
>So the SRL is essentialy
> free.  To use a moving pointer two 4 bit counters would have to be
> added, so I am sure they would not want to do it this way.
>
> Can you use the SRL as a FIFO?  I was not aware that you could change
> the length.  I thought that was a configuration setting.  If they are
> doing that the only extra for the moving pointers would be the 4 bit
> write address counter.
You use a fixed insertion point for writing into the SRL16, but move
the read location by changing the mux address forwards, backwards or
not at all. Takes a moment to understand...
Peter Alfke


Article: 108143
Subject: exporting an image with quartus 2 web edition
From: tthurnherr@gmail.com
Date: 5 Sep 2006 19:46:01 -0700
Links: << >>  << T >>  << A >>
Hi there
I'm trying to export a waveform from the quartus 2 web edition. In the
quartus 2 help, there's a nice explanation how to do that:

>Export Dialog Box (SignalTap II Logic Analyzer)
>
>--------------------------------------------------------------------------------
>You open this dialog box by clicking Export on the File menu.
>
>Exports the current SignalTap II waveform data to a Comma-Separated Value File (.csv), >Vector Table Output File (.tbl), Value Change Dump File (.vcd), Vector Waveform File (.vwf), >JPEG File Interchange Format (.jpg), or Bitmap File (.bmp).

Unfortunately, when i execute the described action, I can only export
VHDL testbench files (*.vht) and Verilog testbench files (*.vt).

Can anybody tell me if this is because of the licence, or if i'm doing
something else wrong?

My version is 6.0 build 202 SJ Web Edition, with service pack 1
installed. 

Thanks a lot and have a nice day


toto


Article: 108144
Subject: Re: fastest FPGA
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 06 Sep 2006 03:04:15 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
> I gave this a bit more thought and realized that there is already a lot
> of circuitry in the LUT.  It has the output mux (read decode) and the
> write address decode and the LUT RAM bits are already in a shift
> register for loading configuration data.  So the SRL is essentialy
> free.  To use a moving pointer two 4 bit counters would have to be
> added, so I am sure they would not want to do it this way.
> 
> Can you use the SRL as a FIFO?  I was not aware that you could change
> the length.  I thought that was a configuration setting.  If they are
> doing that the only extra for the moving pointers would be the 4 bit
> write address counter.

The SRLs are absolutely useable as FIFOs with the only caveat that 
they're in the same time domain.  The output value is a combinatorial 
result from the 16 values in the memory and the LUT address: the 
standard F1-F4 or G1-G4 lines.  If the data gets shifted in right when 
you're trying to read, no amount of coordination with the output mux 
select will give you a static value.  So... used in a synchronous 
fashion, these are *great* for variable length FIFOs rather than just 
static delay lines.  The pointer comes down to something like:

   always @(posedge clk) SRLsel[3:0] <= SRLsel[3:0] + ld - rd;

The up/down count takes more than one level of logic but it sure is 
quick & easy to code.  It infers pretty well as long as you don't try to 
add a reset to the mix.  The register coupled to the LUT in the slice 
also has an enable that can be different than the write enable (shift 
enable) allowing a little more flexibility.

Although the early SRLs were a bit slower than one might want in-system, 
the current generation of Spartan devices - as I've been assured by the 
Xilinx support folks - can reach the full speed of the device if you use 
the slice register from the LUT/SRL output.

Article: 108145
Subject: Re: Undergrad project-8051 specifications??
From: joseph2k <quiettechblue@yahoo.com>
Date: Wed, 06 Sep 2006 03:30:03 GMT
Links: << >>  << T >>  << A >>
Tim Wescott wrote:

> Antti wrote:
> 
>> neha.karanjkar@gmail.com schrieb:
>> 
>> 
>>>Hi all.
>>>I'm an undergrad student doing a year long project on designing an 8051
>>>variant for FPGA.
>>> We're required to decide upon  the specifications, by targeting any
>>>particular application.
>>>I'd be really thankful for any suggestions for the applications....
>>>  Could someone guide me to sites that offer a comparison, &
>>>applications of available 8051 cores?
>>>
>>>thanx in advance
>> 
>> 
>> there are many many many free and commercial 8051 derivates. spending a
>> year to make another clone really doesnt make sense unless there is
>> something around the 8051 that makes the whole SoC different from the
>> current offerings.
>> 
>> Antti
>> 
> It's a _class project_ for crying out loud!  The real point is to start
> from something that's pretty fully specified, then make it work in the
> real world.  Applicability has little to do with it.
> 

At least some of that depends on whether the student wants a "A" or less.  
"A" level work exhibits general knowledge of where 8051's have been / are
used and either does one of those things better or does something new and
challenging.

-- 
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
  --Schiller

Article: 108146
Subject: Re: Please help me with (insert task here)
From: "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl>
Date: Wed, 6 Sep 2006 07:54:52 +0200
Links: << >>  << T >>  << A >>
"Jim Stewart" <jstewart@jkmicro.com> wrote in message
news:bvSdncft9qz4kWPZnZ2dnUVZ_uydnZ2d@omsoft.com...
> An SCR, placed across the terminals of a decent
> sized gelcell will give a very rewarding blue
> flash followed by an orange fireball after it's
> been turned on.

We used to put those 0.5mm pencil fillings across the 220V terminals (the
screw type that also accepts banana plugs) at the test benches at school....
Especially the softer types (4-6B) produced a nice soft orange flash
followed by enormous amounts of smoke :-)

Meindert



Article: 108147
Subject: Open-source CableServer for Impact on sourceforge.net
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 5 Sep 2006 23:22:24 -0700
Links: << >>  << T >>  << A >>
Hi All,

Here is a open-source CableServer replacement for Xilinx Impact.
Currently Parallel III and Altera ByteBlaster are supported, but any
3rd party programmer cable can be implemented easily and can be used
from Impact. This open-source implementation can be used as a
Programmer Cable SDK for Impact.

I've tested only Impact 8.2, if anybody has any problem with 7.1,
please let me know!

Impact and Xilinx CableServer communication are very pooly written.
There is no error recovery at all. If server stops, Impact GUI will
crash. To avoid this you must disconnect server from GUI using
Output/Cavble disconnect menu.

http://sourceforge.net/projects/xilprg
http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209

Regards,

Zoltan


Article: 108148
Subject: Re: Forth-CPU design
From: "J Thomas" <jethomas5@gmail.com>
Date: 6 Sep 2006 00:12:59 -0700
Links: << >>  << T >>  << A >>

rickman wrote:
> jacko wrote:

> > just wondering if grey code (1 bit change) addressed stack memory might
> > be useful for cutting down carry chain logic for pre-post dec/inc
> > addressing??
>
> Why bother?  On FPGAs carry chain logic is free, fast and the easy
> path.  I guess you are thinking custom chip, eh?

I wasn't sure I understood the question. Is it to reduce the worst-case
speed for the increment? A traditional carry-type grey code implement
has a worst case just as bad as binary, but it sounds like he's
thinking about dedicating the space for a faster method.

But likely I misunderstood. Why would he need the increment to be fast
when something else would surely be slower anyway? And I'd expect a
binary increment to take less space.


Article: 108149
Subject: XPS : Compiler advanced options...
From: Alfre <>
Date: Wed, 6 Sep 2006 00:52:33 -0700
Links: << >>  << T >>  << A >>
Hi all.

I would like to link my own library file with the standard ones created in EDK by Xilinx. So I had thought to use the advanced compiler options--> I mean set a directory in the -L for the linker and moreover the file in the -l. But it doesn't work: i see the compiler get these options but an error says that not found the library... I'm sure and " have checked more times the path and the library name.

Why? Could be a bug?

I'm using EDK 8.1.02i.

Thanks in advance.

Cheers, Al.



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