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 81525

Article: 81525
Subject: Re: iMPACT Boundary-Scan Error
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 26 Mar 2005 03:20:29 -0800
Links: << >>  << T >>  << A >>
try the File-Start Debug Chain to see if the JTAG is alive at all. From what you wrote I would say either cable is broke or bad contact or the FPGA is fully dead. If cable is OK, the JTAG pins connected then you should see the device in impact no matter the config setting on fpga

antti

Article: 81526
Subject: Re: DSP designs that exceed provided embedded arithmetic hardware
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sat, 26 Mar 2005 14:18:13 +0100
Links: << >>  << T >>  << A >>
Ken wrote:

> Hi folks,
> 
> This question is aimed at those who have created designs including DSP using 
> a device family containing dedicated arithmetic silicon (e.g. Xilinx 
> DSP48/18x18s/Altera DSP blocks):
> 
> On what % of designs you have completed did you run out of dedicated 
> arithmetic blocks and have to implement filters in the main logic fabric?

We've some big DSP applications on VirtexIIs with 100% of multipliers or 100% of Ram 
blocks used (and over 90% of logic used).
In VIIs, this sometimes is tricky since they share ressource, and this can put some 
restrictions on how the blocks (DSP+Ram) can be parameterized to coexist.
You may also find difficult to partition the operators between dedicated and logic 
since the synthesis tool may have a global flag... Manual inference is often the 
solution.
Globally, we've been pleasantly surprised by the routability of very dense arithmetic 
(DSP) designs (both in Xilinx and Altera parts btw).
Last, we're not using (well almost not) ready-made IPs, so we retain control of how 
the operators are inferred (and which variant), so it's probably a safer situation.

Bert Cuzeau

Article: 81527
Subject: Re: When will outsourcing hit FPGA'ers?
From: "Symon" <symon_brewer@hotmail.com>
Date: Sat, 26 Mar 2005 05:34:11 -0800
Links: << >>  << T >>  << A >>
"anony" <none@nowhere.net> wrote in message 
news:A4N0e.2320$zl.563@newssvr13.news.prodigy.com...
> So is it just a matter of time before a lot of the
> FPGA-jobs/employment migrate overseas?
>
That all depends on where you live!
Syms. 



Article: 81528
Subject: Re: Altera's power consumption net seminar
From: "Symon" <symon_brewer@hotmail.com>
Date: Sat, 26 Mar 2005 05:39:17 -0800
Links: << >>  << T >>  << A >>
"che_fong" <che_fong@netzero.com> wrote in message 
news:1111786662.899977.24100@g14g2000cwa.googlegroups.com...
>
>
> These guys are all biased.  When you look at details, they show their
> side of the story.  Power ? Big deal !  There are other more pressing
> issues !  High end FPGAs hardly go in portable devices ! ;-)
>
Well if you have a " Power ? Big deal ! " attitude, it's gonna be difficult 
for you to design a portable device with a high-end FPGA. Those of us who 
know that power _is_ a big deal seem well enough able to do it though.
Cheers, Syms. 



Article: 81529
Subject: Initializing Altera MEGARAMs in simulation
From: "Peter Y" <nospam@thankyou.com>
Date: Sat, 26 Mar 2005 09:57:11 -0500
Links: << >>  << T >>  << A >>
For whatever reason, I need to be able to initialize the M-RAMs in Altera 
chips, and I need to do this in a timing simulation, for which I use 
Modelsim.

So I've hacked the stratix_atoms simulation libraries to initialize them, 
and that works fine.  I can start a simulation, look in those memories and 
everything they have is correct, but now the simulation is incorrect. 
Anyone know why this might be?  Are the columns of the RAM permuted for 
timing reasons, is it endianness, or anything else?

I need to do this with a lot of designs, so setting break points and using 
the Update Embedded Memories in Quartus' simulator is annoying.  Any other 
suggestions? 



Article: 81530
Subject: Re: cheap Xilinx tricks
From: nospam <nospam@nospam.invalid>
Date: Sat, 26 Mar 2005 16:07:28 +0000
Links: << >>  << T >>  << A >>
"Bob" <nimby1_notspamm_@earthlink.net> wrote:

>The first problem is that the LVDS for Spartan 3 is only defined for VCCO of
>2.5V. So, a given IOB cannot run LVDS and, for example, LVTTL (3.3V I/O) at
>the same time. 

VCCO only supplies differential drivers the differential receivers run from
VCCAUX so I see no reason why you can't have LVDS receivers in a bank with
3.3v VCCO. I have done this without problem but so far only on a prototype.

For the OP I suggest you look at an IOB with the FPGA editor and see if you
can find a combination of checkboxes to give you what you want. I suspect
there isn't but if there is you will have to find out how to make the tools
give you what you want. 



Article: 81531
Subject: Re: cheap Xilinx tricks
From: John Larkin <jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX>
Date: Sat, 26 Mar 2005 08:21:05 -0800
Links: << >>  << T >>  << A >>
On Sat, 26 Mar 2005 08:45:26 -0000, "John Adair"
<removethisthenleavejea@replacewithcompanyname.co.uk> wrote:

>If you add the I/O symbols like  IBUFGDS_LVDS_25(clock input) or
>IBUF_LVDS_25(normal input) to your schematic you will get a proper LVDS
>input implementation. With Spartan-3 you will need an external terminating
>resistor for input LVDS. For information on buffer types etc look in the
>"libraries guide". You will need to dig for the LVDS in particular as text
>searching this document does work well for finding a particular I/O standard
>buffer type.
>
>I think you can mix LVDS (input only and not DCI mode) with a 3.3V output
>but either check that with your FAE or try in on a development board. I have
>done this exactly on a Virtex2-Pro but personally have not tried this
>combination on Spartan-3.
>

What we want to do works fine electrically - we've tried it - but it
takes three pins. We have to externally connect the tristate output to
one of the LVDS inputs. What I want to do is persuade the ISE compiler
to make the connection internally so we can save a pin each time we do
this.

I think all the required hardware exists inside the S3 I/O cell. What
we can't do is get the ISE software to configure it that way. I'm
fishing for ideas on that.

Thanks,

John


Article: 81532
Subject: Re: cheap Xilinx tricks
From: "Bob" <nimby1_notspamm_@earthlink.net>
Date: Sat, 26 Mar 2005 17:04:30 GMT
Links: << >>  << T >>  << A >>

"nospam" <nospam@nospam.invalid> wrote in message
news:752b4191vjqonk09q53ufd5iltbjpthfap@4ax.com...
> "Bob" <nimby1_notspamm_@earthlink.net> wrote:
>
> >The first problem is that the LVDS for Spartan 3 is only defined for VCCO
of
> >2.5V. So, a given IOB cannot run LVDS and, for example, LVTTL (3.3V I/O)
at
> >the same time.
>
> VCCO only supplies differential drivers the differential receivers run
from
> VCCAUX so I see no reason why you can't have LVDS receivers in a bank with
> 3.3v VCCO. I have done this without problem but so far only on a
prototype.
>
> For the OP I suggest you look at an IOB with the FPGA editor and see if
you
> can find a combination of checkboxes to give you what you want. I suspect
> there isn't but if there is you will have to find out how to make the
tools
> give you what you want.
>
>

I think you're correct about the LVDS input diff amp running from VCCAUX.
However, since VCCAUX is 2.5V (for S3), I wonder if you could still
overdrive the 2.5V input stage by the 3.3V topside output fet. It may work,
but the long-term reliability may be in question.

I'd still like to know why John needs to mix LVDS and a single-ended output.
It's probably something evil or illegal ;-O

Bob



Article: 81533
Subject: Re: When will outsourcing hit FPGA'ers?
From: Philip Freidin <philip@fliptronics.com>
Date: Sat, 26 Mar 2005 17:50:57 GMT
Links: << >>  << T >>  << A >>
On Sat, 26 Mar 2005 05:34:11 -0800, "Symon" <symon_brewer@hotmail.com> wrote:

>"anony" <none@nowhere.net> wrote in message 
>news:A4N0e.2320$zl.563@newssvr13.news.prodigy.com...
>> So is it just a matter of time before a lot of the
>> FPGA-jobs/employment migrate overseas?
>>
>That all depends on where you live!
>Syms. 

Vagabond!


Philip Freidin
Fliptronics

Article: 81534
Subject: Re: cheap Xilinx tricks
From: John Larkin <jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX>
Date: Sat, 26 Mar 2005 10:45:58 -0800
Links: << >>  << T >>  << A >>
On Sat, 26 Mar 2005 17:04:30 GMT, "Bob"
<nimby1_notspamm_@earthlink.net> wrote:

>
>"nospam" <nospam@nospam.invalid> wrote in message
>news:752b4191vjqonk09q53ufd5iltbjpthfap@4ax.com...
>> "Bob" <nimby1_notspamm_@earthlink.net> wrote:
>>
>> >The first problem is that the LVDS for Spartan 3 is only defined for VCCO
>of
>> >2.5V. So, a given IOB cannot run LVDS and, for example, LVTTL (3.3V I/O)
>at
>> >the same time.
>>
>> VCCO only supplies differential drivers the differential receivers run
>from
>> VCCAUX so I see no reason why you can't have LVDS receivers in a bank with
>> 3.3v VCCO. I have done this without problem but so far only on a
>prototype.
>>
>> For the OP I suggest you look at an IOB with the FPGA editor and see if
>you
>> can find a combination of checkboxes to give you what you want. I suspect
>> there isn't but if there is you will have to find out how to make the
>tools
>> give you what you want.
>>
>>
>
>I think you're correct about the LVDS input diff amp running from VCCAUX.
>However, since VCCAUX is 2.5V (for S3), I wonder if you could still
>overdrive the 2.5V input stage by the 3.3V topside output fet. It may work,
>but the long-term reliability may be in question.
>

As I said, we did it with an external connection, and it worked great.

Our only problem is the danged compiler. If you look at figure 1 of
the DS099-2.pdf thing, it sure looks like all the wires I want are
there. In fact, if we can take this diagram literally, the ttl
tristate driver is already connected to one pin of the LVDS receiver.

>I'd still like to know why John needs to mix LVDS and a single-ended output.
>It's probably something evil or illegal ;-O

Both. It's so terrible that if I told you, The Authorities would take
away my slide rule.

John


Article: 81535
Subject: Re: cheap Xilinx tricks
From: nospam <nospam@nospam.invalid>
Date: Sat, 26 Mar 2005 19:04:31 +0000
Links: << >>  << T >>  << A >>
"Bob" <nimby1_notspamm_@earthlink.net> wrote:

>I think you're correct about the LVDS input diff amp running from VCCAUX.
>However, since VCCAUX is 2.5V (for S3), I wonder if you could still
>overdrive the 2.5V input stage by the 3.3V topside output fet. It may work,
>but the long-term reliability may be in question.

I doubt it is a problem. If you look at the simplified IOB schematic all
receiver styles appear to be connected to the pin regardless of the pin
being configured as in or out with whatever standard. I can only assume all
receivers can take the worst a pin can output. 

The pin clamp diode is connected to VCCO. The datasheet absolute maximum
input voltage ratings are specified in relation to VCCO only (apart from
dedicated pins which appear to run from VCCAUX). 



Article: 81536
Subject: Re: cheap Xilinx tricks
From: Phil Hays <Spampostmaster@comcast.net>
Date: Sat, 26 Mar 2005 11:11:41 -0800
Links: << >>  << T >>  << A >>
John Larkin wrote:

>I think all the required hardware exists inside the S3 I/O cell. What
>we can't do is get the ISE software to configure it that way. I'm
>fishing for ideas on that.

I've done similar things in the past by:

Compiling the design.
Converting to XDL.
Edit the XDL with a script (Perl would be a good choice)
Build the design.

Type XDL at a command prompt.

"XDL is also a fully featured Physical Design language that
provides direct read and write access to Xilinx's proprietary
Native Circuit Description (NCD). This access enables all
users to write tools to address their individual FPGA
design needs."


Another method is to use FPGA_editor to create a hard macro, and put
this into your design.  This probably requires two wrapper files, one
for simulation and one for synthesis.


--
Phil Hays
Phil-hays at posting domain (- .net + .com) should work for email


Article: 81537
Subject: some +. for Altera
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 26 Mar 2005 20:24:57 +0100
Links: << >>  << T >>  << A >>
Hi

first - I am a very Xilinx biased (possible because I have way more Xilinx
boards)
but the latest Quartus seems really easy and in some cases better than X
tools
(at least the built in programmer is FASTER to use than impact)

Story:
After getting a nice application tested on Xilinx FPGA I just out of
curiosity
tried to port to Altera devices, the only problem I had was related to lack
of documentation on the cyclone_jtag and maxii_jtag, after solving those
the original xilinx code compiled without changes and worked too :)

http://wiki.openchip.org/index.php/OpenChip:FpgaFreqMeter

after first success with Cyclone, I tried it on MAX2 and worked again :)

MAX2 is really nice well its not so much an PLD but more like
Xilinx XC2K reinvented and made flash based ;) anyway it is
really a heavy player on the flash device arena as the other
suppliers Atmel and Lattice are not yet shipping their low-cost
flash FPGAs

Antti





Article: 81538
Subject: Bus expansion
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Sat, 26 Mar 2005 21:26:21 +0100
Links: << >>  << T >>  << A >>
Hello,

how do I extend buses in Quartus Schematic Editor?
Say, for instance, there is an input "phase_offset[23..0]"
and a component which expects a 32-bit wide vector.
I would like to map phase_offset to the upper 24 bits
of the vector and hardwire the remaining bits to 0.
In VHDL it would be:

 [...]  port map (vec => phase_offset & "00000000") [...]

For non-constant data I have already figured it out:

1. Create a bus using the Orthogonal Bus Tool;
2. Select the bus and then in its properties fill the
"name" field with e.g. shifter_out[29..14], phase_out[15..3].

However, it does not work with constants.

My attempt: phase_offset[23..0],0,0,0,0,0,0,0,0
Quartus: Error: Node "0" is missing source

My attempt: phase_offset[23..0],"00000000"
Quartus: Error: Illegal wire or bus name phase_offset[23..0],"0000000" of
type signal

My attempt: use the megafunction wizard to insert a constant
by the name of "Z" and value 0, then write
phase_offset[23..0],Z,Z,Z,Z,Z,Z,Z,Z
Quartus: Error: Node "Z" is missing source.

So then, how should I express my intentions? :-)

    Best regards
    Piotr Wyderski


Article: 81539
Subject: Re: iMPACT Boundary-Scan Error
From: "Darien A. Gothia" <daragoth@kuririnmail.com>
Date: 26 Mar 2005 13:34:21 -0800
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> try the File-Start Debug Chain to see if the JTAG is alive at all.
>From what you wrote I would say either cable is broke or bad contact or
the FPGA is fully dead. If cable is OK, the JTAG pins connected then
you should see the device in impact no matter the config setting on
fpga
>
> antti


I'm pretty sure the FPGA isn't dead; I had it load the factory default
configuration from the Platform Flash device and it worked fine.

I've tried running the Debug Chain prior to posting my original
message, but it seemed the JTAG was okay.  Like I said, I'm a beginner
to this, but looking online I was somewhat able to figure out how it
works and tried making sure the FSM was okay.  I tested every
transition and they all worked.  I didn't try doing the other tests the
debug mode gives you though, should I do this?  If so, is there a place
where I could get a tutorial on how to do so?  Thanks a lot for your
help.

-DG


Article: 81540
Subject: Re: Altera's power consumption net seminar
From: eternal_nan@yahoo.com (Ljubisa Bajic)
Date: 26 Mar 2005 13:40:00 -0800
Links: << >>  << T >>  << A >>
Power is important even in non-portable applications. In telecomm
applications, which are a  major market for fpga's, heat dissipation
is a very real problem and determins to some extent how densely racks
can be stacked with linecards or similar electronics. Not to mention
that no-one likes their
power bills to be larger than neccessary.

Ljubisa Bajic
ATI Technologies
--- My opinions do not represent those of my employer

"Symon" <symon_brewer@hotmail.com> wrote in message news:<42456556_2@x-privat.org>...
> "che_fong" <che_fong@netzero.com> wrote in message 
> news:1111786662.899977.24100@g14g2000cwa.googlegroups.com...
> >
> >
> > These guys are all biased.  When you look at details, they show their
> > side of the story.  Power ? Big deal !  There are other more pressing
> > issues !  High end FPGAs hardly go in portable devices ! ;-)
> >
> Well if you have a " Power ? Big deal ! " attitude, it's gonna be difficult 
> for you to design a portable device with a high-end FPGA. Those of us who 
> know that power _is_ a big deal seem well enough able to do it though.
> Cheers, Syms.

Article: 81541
Subject: Re: some +. for Altera
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sun, 27 Mar 2005 03:15:00 +0200
Links: << >>  << T >>  << A >>
Hi Antti,

At ALSE, we design all kinds and brands of FPGAs and have been doing so for years and 
years (the first FPGA I dealt with was a XC2000 under XDE,- 17? years ago-). Until 
less than two years ago, we did design more Xilinx than Altera parts (we respect the 
customer's decision when he wants a particular device or family).
And ISE is based on a technology (Synario & ECS) that I supported even before it had 
a name -and I more than liked this tool, still use it occasionnally-.
When Quartus was launched, it was terrible, and stayed that way for a while. However...

IMO and backed up by concrete experience, I would say that the progress made by 
Altera with Quartus tools (and devices) over the last two years has been tremendous 
and probably gone very much unnoticed, until recently.

Quartus II has progressed a lot, and it's not over...
The new device architectures (like MaxII) are as surprising as they prove efficient 
concretely. We love the Cyclone family : cheap, extremely low power and they are 
usually faster than the usual applications require even in their lowest speed grades.

- As of tool quality, I keep my fingers crossed, but I don't fear loading the latest 
QII release (even beta) and start using it right away in the middle of challenging 
designs. I usually let other tools "ripe" a bit.

- As of integrated synthesis, both for QOR and language coverage (VHDL) I won't 
comment, by fear of offending third party tools vendors. I've witnessed 30% smaller 
designs with QII v4.2 as compared with older versions, and I have problem with 
standard descriptions with XST which are perfectly supported by QII now. There are 
still a few things I would like to see added in QII (like character'pos), but they 
should be in 5.0 or 5.1 and I stopped asking for VHDL QOR improvement.

- QII's Static Timing Analysis + constraint-driven P&R + Physical synthesis are 
impressive. Most FPGA users need to be educated in order to take advantage of it. 
Physical synthesis can for example fix design errors by automatically compensating 
data or clock delays, it can precisely adjust delays for SDRam interfaces, etc...
I'm not saying other tools don't have this technology, just that users are often 
unaware that it's in Quartus II.

- Tcl/Tk and command-line tools are so easy to use ! (you find a Tcl console in 
almost all tools now -yes: ModelSim too : just type parray env-).
You can build and download an FPGA with a single double click on a batch file and
never see the GUI if you want to, with a trivial script. This contributes greatly to 
the ease of use of our Tornado FPGA Board and Tornado Education Kit.

- SoPC is probably the strongest advantage I see as of now for Altera. The NIOS II 
processor, the Avalon switch fabric, and the Tools around them have proved their 
value. I know several companies even purchased the NIOS license... for ASICs.

- RTL and Technology graphical Views are very decent, and the cross-probings between 
all the different descriptions is handy when investigating.

- The Constraints Editor, initially clumsy, is now very powerful & versatile.
You can for example easily import export CSV pin assignments (with PCB tools or 
Excell). It is well organized and easy to use.

- The GUI commands have their immediately visible Tcl counterpart, so it's a trivial 
task to automate even the most complex settings.
When we deliver an FPGA design to a customer, we only have HDL source files and a 
single "does-it-all" Tcl script (which also includes the pin & other assignments).

- SignalTap and InSystem Memory Contents Editors are _VERY_ easy to use (and cheap if 
not free).

- LogicLock makes floorplanning (almost) easy when the need comes.

- JTag (Jam) player is nice in some cases. Not sure Xilinx has the equivalent public 
code. (well probably)

- I think the cost is lower for the full version of QII compared with Foundation and 
equivalent options (ChipscopePro) but prices move often.

- It's very easy to integrate other tools within QII, or to integrate QII inside 
other tools. I don't think any other tool is as open as QII.

- OpenCore IP protection scheme is clever. It lets you play with IPs as you please.
  The megawizzard is also easy to use.

- Power estimation in 4.2 is now simple to use, both as an early tool, then along 
when the design gets refined.

- Early estimators, and fast assignment verifiers, Design assistant, Performance 
advisors definitely make the designer's life easier.

- Never used DSE nor distributed computing (hope I won't have to), but I know it's there.

- More new features are announced.

As far as I know, Altera bought a couple of small but very brilliant companies that 
are behind these technology leaps.

On the minus side for Altera I would mention :
- Truly incremental P&R is coming, but still not quite here yet. Many users are 
impatient (it will be welcome for the big chips).
- For simple designs : Analysis & Elaboration must be run in order to view the 
hierarchical dependencies (ISE does this automatically), not a real issue but it's a 
bit unexpected for ISE users when they try QII. For big designs, you don't let the 
tool guess what it should compile and in which order; we use scripts.

It's very easy to use Quartus II and simply not unleash its power even when you need 
it. That's why we made efforts to build and offer (with lots of help from Altera) an 
extensive 2-days Training course in France, and we get an excellent feedback on it.

What we try to say to our customers is that Quartus II now deserves spending some 
time learning its many features and capabilities. For simple things, not much if 
anything at all is necessary (a batch file can do everything), but challenging tasks 
will be much simpler with a good understanding of the engine under the hood.
---
As of Xilinx, I haven't tested 7.1 yet. Has anyone feedback & experience to share ?

Obviously, we don't fear designing Xilinx chips (we design mostly very complex 
applications now) and ISE is easy to use. Besides the lack -as far as I know- of easy 
and well documented scripting (Tcl/tk), my worst grief is that it's way too easy to 
have the focus on the wrong design entity :-)  This feature didn't exist in Synario, 
and it was much less error-prone. Definitely minor, but irritating. With QII, you can 
change your focal point, but you can't do it without noticing.
VHDL synthesis (XST) has also some issues and weaknesses, and I sometimes have to 
partially rewrite some of our IPs for this reason (I complained a couple of times 
about poor support for qualified expressions for example).
I find Impact's look and use a bit clumsy and old-looking, but it works. I guess it 
has been improved in 7.1.
I also hope they removed or rewrote these offending VHDL "examples" !!! (like j2c_vhd 
on top of my head).

On the X. side, I found Xilinx Tech Support outstanding (maybe only ModelSim's does 
impress me even more).

I loved ECS in Synario and first ISE versions, with the generic symbol library and 
all the cool utilities related with HDL, but I don't like what it became in the 
latest versions of ISE. But schematic editors are usually a matter of personal taste 
(I'm not a huge fan of QII's schematic editor either) and we don't use them much if 
at all (top levels only, if we find enough motivation).

If you plan to stay with Xilinx, don't start using Quartus ;-)

Things are very cyclic in this industry, so I expect an effort from the competition 
to regain the lost terrain. It makes things interesting for us to watch. The good 
news are that the end-user is usually the winner on the end, with powerful and 
affordable tools and devices. But high-end FPGAs and applications are bringing us 
lots of challenges : high level descriptions and modelling, ABV, high-speed design, 
power issues, P&R challenges, IPs reuse, collaborative design... we'll see.


Bert Cuzeau

--- The opinions above are my own only.
--- I may be wrong on some issues.
--- If you think so, or believe I am unfair in any way, let me know.


Antti Lukats wrote:
> Hi
> 
> first - I am a very Xilinx biased (possible because I have way more Xilinx
> boards)
> but the latest Quartus seems really easy and in some cases better than X
> tools
> (at least the built in programmer is FASTER to use than impact)
> 
> Story:
> After getting a nice application tested on Xilinx FPGA I just out of
> curiosity
> tried to port to Altera devices, the only problem I had was related to lack
> of documentation on the cyclone_jtag and maxii_jtag, after solving those
> the original xilinx code compiled without changes and worked too :)
> 
> http://wiki.openchip.org/index.php/OpenChip:FpgaFreqMeter
> 
> after first success with Cyclone, I tried it on MAX2 and worked again :)
> 
> MAX2 is really nice well its not so much an PLD but more like
> Xilinx XC2K reinvented and made flash based ;) anyway it is
> really a heavy player on the flash device arena as the other
> suppliers Atmel and Lattice are not yet shipping their low-cost
> flash FPGAs
> 
> Antti
> 
> 
> 
> 

Article: 81542
Subject: Multi-FPGA PCB data aggregation?
From: Eric <acetylcholinerd@gmail.com>
Date: Sat, 26 Mar 2005 20:24:45 -0500
Links: << >>  << T >>  << A >>
Hello! I'm trying to build a 20-FPGA (spartan-3s, XC3S400-TQ144s) board
for a class project to investigate the use of FPGA arrays for accelerating
scientific competition. The idea was to have a 66 MHz 16-bit
single-ended shared TX bus sending 125 MBps to each FPGA, and a shared 66
MHz 16-bit data aggregation bus where a bus controller would poll each
FPGA sequentially to place its output data onto that bus. 

After discussions with some signal-integrity-leery friends, I'm no longer
convinced that a 12"x12" 20 IC board at 66 Mhz with single-ended buses is
such a good idea. I've been reading the various datasheets on doing LVDS
and DDR signaling. Multidrop LVDS is still a bit tricky, evidently, but to
cut down on trace number I might be able to go to 125 MHz DDR 4-pair LVDS
for the TX bus; the problem I'm having is with the data aggregation bus. 

Could the aggregate data bus be structured in a similar manner, with:
a.) all FPGAs connected to the 4 DDR LVDS pairs? 
b.) a single master, with a separate output enable line to each of the 20
FPGAs

Such that when FPGA n is output-enabled, it would drive it's m nibbles of
data onto the output aggregation bus. But this would require FPGA n to
drive its pins within 4 ns; this sounds nearly impossible. 

Are there any common solutions I'm missing? One thought was to aggregate
all of the data from the FPGAs via dedicated serial links and do clock
recovery at the bus master; this would require recovering 20 separate
clocks, alas, and with the spartan 3s we don't have quite that many DCMs. 

An obvious solution is "do an IBIS simulation, duh" but we don't
have access to the sort of high-end signal integrity simulation software
that this would require. 

Can anyone with spartan-3 serial interconnect experience offer
suggestions as to how to make this work, either through different
LVDS configurations or interconnect topolgies? 

Thanks for any advice you
can give,
    ...Eric

Article: 81543
Subject: Re: Multi-FPGA PCB data aggregation?
From: "Marc Randolph" <mrand@my-deja.com>
Date: 26 Mar 2005 17:41:49 -0800
Links: << >>  << T >>  << A >>

Eric wrote:
> Hello! I'm trying to build a 20-FPGA (spartan-3s, XC3S400-TQ144s)
board
> for a class project to investigate the use of FPGA arrays for
accelerating
> scientific competition. The idea was to have a 66 MHz 16-bit
> single-ended shared TX bus sending 125 MBps to each FPGA, and a
shared 66
> MHz 16-bit data aggregation bus where a bus controller would poll
each
> FPGA sequentially to place its output data onto that bus.
>
> After discussions with some signal-integrity-leery friends, I'm no
longer
> convinced that a 12"x12" 20 IC board at 66 Mhz with single-ended
buses is
> such a good idea. I've been reading the various datasheets on doing
LVDS
> and DDR signaling. Multidrop LVDS is still a bit tricky, evidently,
but to
> cut down on trace number I might be able to go to 125 MHz DDR 4-pair
LVDS
> for the TX bus; the problem I'm having is with the data aggregation
bus.
>
> Could the aggregate data bus be structured in a similar manner, with:
> a.) all FPGAs connected to the 4 DDR LVDS pairs?
> b.) a single master, with a separate output enable line to each of
the 20
> FPGAs
>
> Such that when FPGA n is output-enabled, it would drive it's m
nibbles of
> data onto the output aggregation bus. But this would require FPGA n
to
> drive its pins within 4 ns; this sounds nearly impossible.

Howdy Eric,

I don't think it necessarily would be, except that there is no telling
how long it will take all the reflections to settle out (highly
dependant upon PCB routing).  One way to cut down on all the
reflections would be to put a weak termination pull resistor, or maybe
AC-termination, at every couple FPGA's.  Don't use the built in pull
resistors - you can't tune tune them, and they are too weak to be used
as anything as a pure weak pull up/down.  But too much termination will
affect rise time.

> Are there any common solutions I'm missing? One thought was to
aggregate
> all of the data from the FPGAs via dedicated serial links and do
clock
> recovery at the bus master; this would require recovering 20 separate
> clocks, alas, and with the spartan 3s we don't have quite that many
DCMs.
> [...]

You haven't said how many spare pins the aggregator FPGA will have, but
my first thought was to do as you mention and use dedicated serial
links for each FPGA, but without the clock recovery.  Instead, just
keep the whole board synchronous: distribute the clock so that it
reaches every FPGA at the same time and put the aggregator FPGA in the
middle.  Use the IOB flops for both output and input, and I think
you'll have plenty of time left over for PCB data prop delay.

Good luck,

   Marc


Article: 81544
Subject: Re: Multi-FPGA PCB data aggregation?
From: Eric <acetylcholinerd@gmail.com>
Date: Sat, 26 Mar 2005 21:21:08 -0500
Links: << >>  << T >>  << A >>
Marc, thanks for the answers!

> I don't think it necessarily would be, except that there is no telling
> how long it will take all the reflections to settle out (highly
> dependant upon PCB routing).  One way to cut down on all the
> reflections would be to put a weak termination pull resistor, or maybe
> AC-termination, at every couple FPGA's.  Don't use the built in pull
> resistors - you can't tune tune them, and they are too weak to be used
> as anything as a pure weak pull up/down.  But too much termination will
> affect rise time.

As I understand it reflections are still a problem with LVDS signalling,
so you're right, this could be a problem. If I've got a shared (multidrop)
LVDS bus with 20 inputs and one driver, I'm also worried about the input
capacitance slowing rise time. Would it be possible to use the DCI on the
spartan-3s to help cut down on reflections? 

> You haven't said how many spare pins the aggregator FPGA will have, but
> my first thought was to do as you mention and use dedicated serial links
> for each FPGA, but without the clock recovery.  Instead, just keep the
> whole board synchronous: distribute the clock so that it reaches every
> FPGA at the same time and put the aggregator FPGA in the middle.  Use
> the IOB flops for both output and input, and I think you'll have plenty
> of time left over for PCB data prop delay.

20 FPGAs * 4 DDR LVDS Pairs = 160 wires, which isn't something I can pull
off with any components I can solder by hand. :( Plus this configuration
is a bit of overkill, as I really only need ~125 MB/sec aggregate
bandwidth (I'm reusing a gigabit ethernet design I did for off-board IO...
UDP/IP in vhdl isn't fun, but it's fast).  

I agree that keeping things synchronous would be best, but then I get
worried about the combined effects of propagation delay and clock skew,
which would seem to easily swamp the 4 ns window for DDR 125 MHz. Is there
any way to use the DCMs on the Spartan-3s to help reduce the effects of
clock skew across the 20 FPGAs? I have to confess that I've never quite
understood how to use the DCMs, even after reading the app notes. 

Thanks again for all the help,
		...Eric



Article: 81545
Subject: Re: Multi-FPGA PCB data aggregation?
From: Phil Short <pjs@switchingpost.nospam.com>
Date: Sun, 27 Mar 2005 06:03:24 GMT
Links: << >>  << T >>  << A >>
On Sat, 26 Mar 2005 20:24:45 -0500, Eric wrote:

> Hello! I'm trying to build a 20-FPGA (spartan-3s, XC3S400-TQ144s) board
> for a class project to investigate the use of FPGA arrays for accelerating
> scientific competition. The idea was to have a 66 MHz 16-bit
> single-ended shared TX bus sending 125 MBps to each FPGA, and a shared 66
> MHz 16-bit data aggregation bus where a bus controller would poll each
> FPGA sequentially to place its output data onto that bus. 
> 
> After discussions with some signal-integrity-leery friends, I'm no longer
> convinced that a 12"x12" 20 IC board at 66 Mhz with single-ended buses is
> such a good idea. I've been reading the various datasheets on doing LVDS
> and DDR signaling. Multidrop LVDS is still a bit tricky, evidently, but to
> cut down on trace number I might be able to go to 125 MHz DDR 4-pair LVDS
> for the TX bus; the problem I'm having is with the data aggregation bus. 
> 
> Could the aggregate data bus be structured in a similar manner, with:
> a.) all FPGAs connected to the 4 DDR LVDS pairs? 
> b.) a single master, with a separate output enable line to each of the 20
> FPGAs
> 
> Such that when FPGA n is output-enabled, it would drive it's m nibbles of
> data onto the output aggregation bus. But this would require FPGA n to
> drive its pins within 4 ns; this sounds nearly impossible. 
> 
> Are there any common solutions I'm missing? One thought was to aggregate
> all of the data from the FPGAs via dedicated serial links and do clock
> recovery at the bus master; this would require recovering 20 separate
> clocks, alas, and with the spartan 3s we don't have quite that many DCMs. 
> 

How about daisy chaining these dedicated serial lines in some fashion,
rather than running them all to the bus master?  The output of each
non-master FGPA goes to the next non-master FPGA, and only the last one
goes to the bus master. This is not without it's intricacies, but
certainly worth considering.

> An obvious solution is "do an IBIS simulation, duh" but we don't have
> access to the sort of high-end signal integrity simulation software that
> this would require.
> 
> Can anyone with spartan-3 serial interconnect experience offer
> suggestions as to how to make this work, either through different LVDS
> configurations or interconnect topolgies?
> 
> Thanks for any advice you
> can give,
>     ...Eric

--

Phil


Article: 81546
Subject: using FPGA JTAG pins as general purpose I/O
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 27 Mar 2005 10:20:15 +0200
Links: << >>  << T >>  << A >>
Hi

I assume this not so widely known and most likely has not so much actual
use, but in some cases it may be useful to use JTAG pins as general purpose
IO, that is to some extent possible with most modern FPGAs. I havent checked
actel and lattice for this issue yet, but for Xilinx and Altera its possible

some explanation and simple source code for Altera and Xilinx is available

http://gforge.openchip.org/projects/jtagasio/
http://wiki.openchip.org/index.php/OpenChip:JTAG_as_IO

it is to be noted that even Altera SCAN primitive has 1 versus 2 (in pre V4
Xilinx) USER commands available Altera SCAN primitive is more flexible than
the Xilinx one. This is due to the fact that in Altera all 4 JTAG pins can
be monitored from FPGA fabric. In case of multi chip chains this allows the
SCAN primitive to be used as JTAG debugger or tracer for scan chain
troubleshooting (when working with other devices in the chain). Xilinx V4 as
of advertized should have this feature too, but I have not verified if it is
actually there or in what form it is useable.

Antti



Article: 81547
Subject: Re: Multi-FPGA PCB data aggregation?
From: "John Adair" <loseitintheblackhole@blackholesextreme.co.uk>
Date: Sun, 27 Mar 2005 09:22:10 +0100
Links: << >>  << T >>  << A >>
Why not use LVDS to connect to a central FPGA. Make a data packet header 
that indicates where data should be routed and where it is from. This way 
data can route to/from any pair of FPGAs or even multiple FPGAs (broadcast 
header).

This way you have point to point links which are relatively easy to route on 
your PCB. Depending on your data needs to you can use multiple links to 
increase data rate or use quadrant, or whatever suits, routing.

Usually with LVDS you should consider if you are going to send a clock with 
the data. Simplest is to send a clock trace pair with the data pair and skew 
between data and clock is minimised. At your data rates you may be able to 
use a central, or common, clock approach but watch for the differences in 
trace lengths causing skew.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development 
Board.
http://www.enterpoint.co.uk

"Eric" <acetylcholinerd@gmail.com> wrote in message 
news:pan.2005.03.27.01.24.45.670450@gmail.com...
> Hello! I'm trying to build a 20-FPGA (spartan-3s, XC3S400-TQ144s) board
> for a class project to investigate the use of FPGA arrays for accelerating
> scientific competition. The idea was to have a 66 MHz 16-bit
> single-ended shared TX bus sending 125 MBps to each FPGA, and a shared 66
> MHz 16-bit data aggregation bus where a bus controller would poll each
> FPGA sequentially to place its output data onto that bus.
>
> After discussions with some signal-integrity-leery friends, I'm no longer
> convinced that a 12"x12" 20 IC board at 66 Mhz with single-ended buses is
> such a good idea. I've been reading the various datasheets on doing LVDS
> and DDR signaling. Multidrop LVDS is still a bit tricky, evidently, but to
> cut down on trace number I might be able to go to 125 MHz DDR 4-pair LVDS
> for the TX bus; the problem I'm having is with the data aggregation bus.
>
> Could the aggregate data bus be structured in a similar manner, with:
> a.) all FPGAs connected to the 4 DDR LVDS pairs?
> b.) a single master, with a separate output enable line to each of the 20
> FPGAs
>
> Such that when FPGA n is output-enabled, it would drive it's m nibbles of
> data onto the output aggregation bus. But this would require FPGA n to
> drive its pins within 4 ns; this sounds nearly impossible.
>
> Are there any common solutions I'm missing? One thought was to aggregate
> all of the data from the FPGAs via dedicated serial links and do clock
> recovery at the bus master; this would require recovering 20 separate
> clocks, alas, and with the spartan 3s we don't have quite that many DCMs.
>
> An obvious solution is "do an IBIS simulation, duh" but we don't
> have access to the sort of high-end signal integrity simulation software
> that this would require.
>
> Can anyone with spartan-3 serial interconnect experience offer
> suggestions as to how to make this work, either through different
> LVDS configurations or interconnect topolgies?
>
> Thanks for any advice you
> can give,
>    ...Eric 



Article: 81548
Subject: Mixing synchronous and asynchronous reset
From: "KCL" <kclo4_NO_SPAM_@free.fr>
Date: Sun, 27 Mar 2005 12:05:37 +0200
Links: << >>  << T >>  << A >>
Is there any hazard to mix synchronous and asynchronous reset?
I am making an RS232 controller and I generally use asynchronous reset in my 
design except in a process that serve to load the control word (indicate 
speed, data length, parity...) where I load the control word when reset = 
'1' or ctr_load ='1' , like that it load the control word at every reset and 
when we ask to reload it by ctrl_load

Regards

Alexis

my code :

decodeur : process(clk,rst)
 begin

 if rising_edge(clk) then
  if ctl_load='1' or rst='1' then
   parity_bit  <= ctl_word(2);
   parity_type  <= ctl_word(1);
   stop_bit   <= ctl_word(0);
   case ctl_word(7 downto 5) is
    when "000" => nb_count <= 
std_logic_vector(to_unsigned((1843200/frequency_0-1),log2(1843200/frequency_0)));
    when "001" => nb_count <= 
std_logic_vector(to_unsigned((1843200/frequency_1-1),log2(1843200/frequency_0)));
    when "010" => nb_count <= 
std_logic_vector(to_unsigned((1843200/frequency_2-1),log2(1843200/frequency_0)));
    when "011" => nb_count <= 
std_logic_vector(to_unsigned((1843200/frequency_3-1),log2(1843200/frequency_0)));
    when "100" => nb_count <= 
std_logic_vector(to_unsigned((1843200/frequency_4-1),log2(1843200/frequency_0)));
    when "101" => nb_count <= 
std_logic_vector(to_unsigned((1843200/frequency_5-1),log2(1843200/frequency_0)));
    when "110" => nb_count <= 
std_logic_vector(to_unsigned((1843200/frequency_6-1),log2(1843200/frequency_0)));
    when "111" => nb_count <= 
std_logic_vector(to_unsigned((1843200/frequency_7-1),log2(1843200/frequency_0)));
    when others =>
   end case;
   case ctl_word(4 downto 3) is
    when "00" => data_bit <= "00010000";
    when "01" => data_bit <= "00100000";
    when "10" => data_bit <= "01000000";
    when "11" => data_bit <= "10000000";
    when others =>
   end case;

  end if;
 end if;
end process decodeur; 



Article: 81549
Subject: Re: Mixing synchronous and asynchronous reset
From: "info_" <"info_"@\\nospam_no_underscore_alse-fr.com>
Date: Sun, 27 Mar 2005 15:04:56 +0200
Links: << >>  << T >>  << A >>
KCL wrote:

> Is there any hazard to mix synchronous and asynchronous reset?
> I am making an RS232 controller and I generally use asynchronous reset in my 
> design except in a process that serve to load the control word (indicate 
> speed, data length, parity...) where I load the control word when reset = 
> '1' or ctr_load ='1' , like that it load the control word at every reset and 
> when we ask to reload it by ctrl_load
> 
> Regards
> 
> Alexis
> 
> my code :
> 
> decodeur : process(clk,rst)
>  begin
> 
>  if rising_edge(clk) then
>   if ctl_load='1' or rst='1' then


Note : the sensitivity list is incorrect : rst should be removed.

Are you sure you want/need to load an input or a register during a reset ?
If ctl_word is internal (registers) as I suspect, why not load asynchronously the 
same default value as these registers ? (like from a package)

Are you sure you want/neet to give these registers a special treatment if the rest of 
your design has an asynchronous reset ?

Mixing both sync and async reset may (according to the FPGA technology and whether 
your reset will use a global or not) not be a good idea. Synchronous reset means 
reset will be part of your datapath. It may then add a logic level which isn't always 
welcome. You may also prevent some tools from dissolve your global reset if you don't 
use it. And you force static timing into analyzing your reset within fmax/Tsu/Th...

Can you explain why you need mixing both and what functionality it allows that not 
mixing would prevent ?

btw : the divider decoding might be expressed in a simpler way.
Like in this example (dtmf coder):

------
-- Fclock is a generic parameter = 60E6 for Tornado
constant fDiv_Max : natural := Fclock/(697*64)-1;
subtype  IntDiv_t is integer range 0 to fDiv_Max;
type Ftable_t is array (0 to 3) of IntDiv_t;
constant F1table : Ftable_t
                  := ( Fclock/(697*64)-1, Fclock/(770*64)-1,
                       Fclock/(852*64)-1, Fclock/(941*64)-1 );
signal Div1 : IntDiv_t;
signal or input Fsel : std_logic_vector (1 downto 0);
.../...
the decoder is then simply :
       Div1 <= F1table(to_integer(unsigned(Fsel)));
which you may register or not, reset or not, load or not etc....
.../...

Using "integer range" for divisors gets rid of the log2 annoyance and corner cases 
(it says you need two bits to divide by 2...) and you have either to use math_real 
(not always supported at synthesis) or a custom function. 0 is also faster to write 
than (others=>'0'), and it means less cumbersome conversions and type conversions.
You must verify that your design rules accept integer ranges (I know some disallow 
them, but mines don't).
Obviously, this also means you should have the freq div in the same module as the 
UART core to benefit from the integer range (they are ruled out in ports). But that 
brings another debated issue of partitioning granularity....

Hope this helps,

Bert



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