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
2017JanFebMarApr2017

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 4375

Article: 4375
Subject: Re: Xilinx xchecker.exe and Windows NT
From: Jim Burns <jim@dcs.gla.ac.uk>
Date: Tue, 22 Oct 1996 09:36:00 +0100
Links: << >>  << T >>  << A >>
On 15 Oct 1996, Thomas Kobler wrote:

> Hello!
> 
> I would like to ask if anybody had success in using the Xilinx
> xchecker cable and xchecker.exe V5.1 od V5.2 under Windows
> NT3.51 to download a LCA? 
> 
> To me it keeps crashing or it ignoring the download cable almost
> every time.
> 
> Any hints?
> 
HI,

I find when using 4nt xchecker runs less well than when when in the
ordinary command window. I was advised by Xilinx that a machine
with windows95 or dos is advisable when using xchecker.

-- Jim

____________________________________________________________________
Jim Burns 				
Research Assistant                Phone +44 141 339 8855 x2069
Department of Computing Science   Fax   +44 141 330 4913  	
The University of Glasgow         Email jim@dcs.gla.ac.uk  			
Scotland                          Url http://www.dcs.gla.ac.uk/~jim
G12 8QQ           
____________________________________________________________________


Article: 4376
Subject: Re: VHDL for Xilinx designs?
From: zz80@digiserve.com (extra z to stop junk mail)
Date: Tue, 22 Oct 1996 08:37:30 GMT
Links: << >>  << T >>  << A >>
> Agreed 100%.  Unfortunately, it is very difficult to work with both
> tools.  I don't know any vendor that provides good integration between
> schematic entry and an HDL ( I still prefer to write state machines
> using HDL and not schematic).

I seem to remember that the old DOS Viewlogic (unrestricted edition
was $28000 here in the UK) had the ability to mix schematic and VHDL
entry. You either opened a Viewdraw window, or opened a VHDL (text
editor, basically) window - and that was it!

I have avoided these massive costs by using CUPL (configured for the
"VIRTUAL" device) for any state-machine blocks, outputting to PALASM
format, converting this to XNF using PDS2XNF & XNFOPT, and for good
measure using Viewgen to produce a schematic from this. Do a batch
file for this, and that's all. Mixing schematic and state-machine
modules is quite easy this way. The generated schematic is good for
impressing people :)

Of course, these are old tools, long unsupported. Nowadays this sort
of capability would cost a small fortune.

Peter.
Article: 4377
Subject: Re: Seeking 16V8: Vcc=3.0-5.0V: Zero standby power.
From: granville@decus.org.nz
Date: 22 Oct 96 21:44:23 +1300
Links: << >>  << T >>  << A >>
In article <WrG8vAAAfgYyEwQ$@rhizik.demon.co.uk>, John Vickers <john@rhizik.demon.co.uk> writes:
> Hi.
> I'm looking for a small PLD (preferably with 16V8 fusemap)
> which will operate over this supply range.  Speed could
> be anyhing.  35ns would be fine.
> 
> Does anyone make such a device ?
> 
> The power comes from a battery-backed (3.6VNiMh) supply,
> which is 5V when the box is powered up, and 3.6-4.3V
> when running off the battery.

 I do not know of a part that meets _ALL_ of the above, but some are close.

 Philips list at P3C18V8Z, but this is rated at 3.6V MAX, and is OTP

 Atmel have a ATF16V8CZ, just out, but this resets at appx 3.8V

 They have a ATF16LV8CZ part number, I assume will be 2.7V-6V ( as are
their FLASH Controllers ) when released.
  
 Some suppliers have a 'sleep' pin4, for pin controlled power down, to
preserve speed - but you have to drive this pin from your system.

 PLD vendors in general are slow to see PLD's in the same Vcc arena as
microcontrollers.
 You also need to watch Icc-Vin specs, and very few have hysteresis, if
chasing the uA region standby's.

 Let me know if you find a part that is 3-5V, Z rated, and available .

hopethis helps - jim
===== Mandeno Granville FAX +64 9 6301 720, 128 Grange Rd Auckland 3 NZ ======
* Developers and suppliers of HDL PLD applications libraries                 *
* for Microcontroller expansion and interface.           		     *
* x51 C, Pascal & Modula-2 Compilers, Simulators, Emulators & FLASH Pgmrs    *
* Contact : Jim Granville . Email above.                                     *
> A 4.8V NiCad/NiMh battery would be rather inconvenient:
> e.g. need to supply 6V for charging.
> -- 
> John Vickers                                            Tel:    +44 1223 560129
> Hardware / Software Person                              Fax:    +44 1223 563698
> The Magic Board Company                                 john@rhizik.demon.co.uk
Article: 4378
Subject: Multipliers on Xilinx FPGAs
From: Reto Zimmermann <zimmi@iis.ee.ethz.ch>
Date: Tue, 22 Oct 1996 12:09:10 +0200
Links: << >>  << T >>  << A >>
I am wondering how multipliers (and other complex arithmetic operations) 
are usually implemented on Xilinx FPGAs. Are there any libraries 
containing more complex arithmetic units than just adders? Is synthesis 
from VHDL an efficient alternative?

Thanks, Reto

-- 
 Reto Zimmermann                    Integrated Systems Laboratory
 zimmi@iis.ee.ethz.ch           Swiss Federal Institute of Technology
 http://www.iis.ee.ethz.ch/~zimmi/       Zurich, Switzerland
Article: 4379
Subject: Re: Multipliers on Xilinx FPGAs
From: matt@esquire
Date: 22 Oct 1996 12:48:43 GMT
Links: << >>  << T >>  << A >>
     Reto Zimmermann <zimmi@iis.ee.ethz.ch> wrote in article <326C9D46.167EB0E7@iis.ee.ethz.ch> :
>
>I am wondering how multipliers (and other complex arithmetic operations) 
>are usually implemented on Xilinx FPGAs. Are there any libraries 
>containing more complex arithmetic units than just adders? Is synthesis 
>from VHDL an efficient alternative?
>
>Thanks, Reto
>

Xilinx has a very good application note on this, using partial products.
Chech www.xilinx.com.  I'm sure it's there somewhere.

-Matt
Article: 4380
Subject: Re: VHDL for Xilinx designs?
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 22 Oct 1996 14:58:17 GMT
Links: << >>  << T >>  << A >>

> Synthesis is a deterministic process!

True, but what is determined is not always knows, and can change with
different revisisons of the compiler, and from vendor to vendor.

> In In IEEE Standard Logic 1164 there is a dontcare value and in 
> HDLs there is something like 'others' or 'default' statements ...

I have seen HDL code that should have been reduced to simple logic take up
half of a chip...and it has taken weeks for the designer to figure out how
to, if it can be done at all, get the synthesizer to generate 'good'
(subjective) code.

> HDL has nothing to do with floorplanning, you have to floorplan a
schematic
> and a HDL design.

The point was that with HDLs you don't have consistent or intellegible
naming of resources, and this makes floorplanning very difficult.

> This one of the big advantage of HDLs.
> With one HDL DEscription I can do a FPGA from XILINX, ACTEL or what you
want
> AND an ASIC. The only thing you need is the appropriate setup file
> and the technology libs. But only one HDL description.

True in most cases.  The problem is since FPGAs are a course grained
architecture, and have special device dependent features, what you have
written to take advantage of one FPGAs architecture, may cause you problems
with another.  I have never known of anyone, my self included, who has been
able to easily migrate from one technology to another using an HDL. 
Luckily, 99% of designs never really do...

> 
>  and require very little library work to add a new device. You
> >may save time writing with HDL up front, but if it is for a fast/dense
> >design, you will spend a great amount of time massaging it, rewriting
it,
> 
> Why? When the counter will get bigger i have to change only a generic .
> Is this a great amount?

I was referring to resource utilization and timing.  Again, it can be a
guessing game as to what the HDL will compile down to, and the consistency
between revisions and vendors of HDL compilers.

> 
> >I have some clients who I told them they would only have to pay me what
I
> >save them.  For one, I converted their VHDL to schematics, went down two
> >part sizes, and two speed grades, saving $46 per board, and the volume
is
> >in the thousands!
> 
> I bet, optimization of the VHDL to better VHDL had saved more than $46!

May be I should have sent the job to you and we could have split the
difference!

Not for FPGAs.  Given todays VHDL compilers, (my experience is with
Viewlogic, Synopsis and Exemplar VHDL compilers for FPGAs), not one of them
is nearly as good as a schematic can be for best speed and resource
utilization.  VHDL is good if you don't care how big your part is, and if
you have a lower speed design.  I am using it for two clients now, and they
are happy with this restriction.  I have two clients that if the design
were done in VHDL, the design wouldn't work.

Having done over 60 IC designs, using HDLs and schematics, for both ASICs
and FPGAs these are my experiences, for others results may vary! 
Experience is a good thing for forming strong opinions....

I like these HDL discussions....

Austin Franklin
darkroom@ix.netcom.com

Article: 4381
Subject: Re: VHDL for Xilinx designs?
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 22 Oct 1996 15:04:30 GMT
Links: << >>  << T >>  << A >>
> I seem to remember that the old DOS Viewlogic (unrestricted edition
> was $28000 here in the UK) had the ability to mix schematic and VHDL
> entry. You either opened a Viewdraw window, or opened a VHDL (text
> editor, basically) window - and that was it!

Xilinx has offered a Windows version of Viewlogic with the Xilinx libraries
only for 1K!  I think that's pretty good...I don't know how much extra VHDL
would have been...  You could use XABEL instead of VHDL for an extra $700
or so...and that integrated nicely, except you couldn't simulate until you
compiled the design to LCA then lca to xnf'd, then xnf to wir...etc.  A bit
of work, but none the less, it worked fine.

Not until recently has Viewlogic offered a good FPGA VHDL compiler in their
tools.  In the past, you had to buy someone elses...like Synopsis (some
large amount of money) and run it on a 'workstation'.

Article: 4382
Subject: Searching Demoboard for Altera Flex8000
From: fnt003@zx2.HRZ.Uni-Dortmund.DE (Dipl.-Ing. D. Lenz)
Date: 22 Oct 1996 15:26:35 GMT
Links: << >>  << T >>  << A >>
Hey everybody out there....

I'm searching after a Demoboard for Flex8000 devices.
Altera says that there aren't exist any Board, but what about third party
developper?
It should have access to all I/O-Pins, configuration Port (Byteblaster) 
and/or space for an EEPROM (e.g. EPC1213PC8) also Voltageregulator ...
I planned to use the EPF8636ALC84-4 (PLCC package) first.

Does anybody know something about this?

Thanx in advance

Domi

****************************************************************
* Fachhochschule Dortmund                                      *
* Fachbereich 6 / Telcom                                       *
* Dipl.-Ing. Dominik Lenz                                      *
* Sonnenstrasse 171                                            *
* 44137 Dortmund                                               *
* Germany                                                      *
* email: fnt003@zx2.hrz.uni-dortmund.de                        *
****************************************************************    
 
Article: 4383
Subject: Re: What are I/O's doing prior to configuration?
From: Marc Baker <marc.baker@xilinx.com>
Date: Tue, 22 Oct 1996 08:50:23 -0700
Links: << >>  << T >>  << A >>
Xilinx devices have I/O that are 3-stated with a weak pull-up during
configuration.  Detail can be found in the Xilinx Data Book
(Acrobat PDF format):

http://www.xilinx.com/partinfo/xa_issue.pdf

Marc Baker
Xilinx
Article: 4384
Subject: Re: What are I/O's doing prior to configuration?
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 22 Oct 1996 09:32:23 -0700
Links: << >>  << T >>  << A >>
Let me explain a bit more, to show that we at Xilinx really put some
thought into this issue:
Before and during configuration, the HDL ( High during configuration )
output is active High, and LDC is active Low. but all outputs that are
not involved in driving the configuration ( which ones are depends on
the configuration mode ) are 3-stated with an internal weak pull-up
transistor in the 30 to 100 kilohm range. 
At the end of configuration, the user has the option of making the FPGA
"come alive" in one of several ways. The completion of configuration is
indicated by the DONE pin going High, but outputs can be activated
either one configuration clock period before, or one period after DONE
going High. Similarily, the internal reset that held all flip-flops and
latches in the reset state during configuration, can be released one
clock period before or one clock period after DONE goes High. Thus the
outputs can be activated while the internal logic is still held in a
reset state, or - with the other option - the internal logic can be
released and allowed to stabilize, before the outputs are being
activated. It's all under your control.
XC4000 and XC5200 have even more elaborate options, where the "waking
up" can be synchronized not to the configuration clock, but to the
user's syetem clock ( assuming they are differnt). 
As an additional precaution against ground bounce caused by a lot of
outputs being activated simultaneously at the end of configuration, we
made sure that, at that moment only, ALLl outputs are slew-rate limited.
See page 13-33 of the 1996 Xilinx data book, now on the web.

Peter Alfke, Xilinx Applications
Article: 4385
Subject: Motorola 68HC16 background debugger
From: wctech@why.net (Larry Chen)
Date: 23 Oct 1996 02:34:29 GMT
Links: << >>  << T >>  << A >>
HC16BGND is an advanced programmer’s interface that helps you to
develop, test, and refine your assembly language programs for 
MOTOROLA’s 68HC16 microcontrollers.  The key features include:
- Run under MS Windows
- Interface through PC’s parallel port
- Motorola suggested 10 pin target connector
- Download and debug HC16 assembly language program in S19 or HEX format
- trace through your code by step through or step over
- set up to 100 breakpoints
- On-screen editing of register and data memory
- On-fly assembly of instruction using mnemonics in program memory
- Open infinite Register, Program, and Data windows
- Exchange data through Windows clipboard
- Easy to use.  Just click on the menu with left mouse or click on 
  the windows’ area.  Everything is self-explained
- Convenient and easy to install due to its parallel port interface.
  You can use laptop to do an on-site demonstration of you products
- Low cost
- 30 day money back guarantee and one year product warranty
For more information or need a demo program,
see http://users.why.net/wctech/hc16bgnd.htm, 
or FTP to FTP.WHY.NET/FTP/PUB/USERS/WCTECH, 
or send email to WCTECH@WHY.NET

Larry Chen
Article: 4386
Subject: Re: VHDL for Xilinx designs?
From: tim_hubberstey@mindlink.bc.ca (Tim Hubberstey)
Date: Wed, 23 Oct 1996 03:45:52 GMT
Links: << >>  << T >>  << A >>
In article <01bbc02a$7f96cf90$207079c0@drt1> "Austin Franklin" <darkroom@ix.netcom.com> writes:
>From: "Austin Franklin" <darkroom@ix.netcom.com>
>Subject: Re: VHDL for Xilinx designs?
>Date: 22 Oct 1996 15:04:30 GMT

>> I seem to remember that the old DOS Viewlogic (unrestricted edition
>> was $28000 here in the UK) had the ability to mix schematic and VHDL
>> entry. You either opened a Viewdraw window, or opened a VHDL (text
>> editor, basically) window - and that was it!

>Xilinx has offered a Windows version of Viewlogic with the Xilinx libraries
>only for 1K!  I think that's pretty good...I don't know how much extra VHDL
>would have been...  You could use XABEL instead of VHDL for an extra $700
>or so...and that integrated nicely, except you couldn't simulate until you
>compiled the design to LCA then lca to xnf'd, then xnf to wir...etc.  A bit
>of work, but none the less, it worked fine.

>Not until recently has Viewlogic offered a good FPGA VHDL compiler in their
>tools.  In the past, you had to buy someone elses...like Synopsis (some
>large amount of money) and run it on a 'workstation'.

Whoa!! Time out! 

I'm sorry but I have to speak up here. Viewlogic _does_ allow you to mix HDL 
and schematic but their VHDL compiler is so bad that I can't recommend using 
it to anyone. We recently tossed our Viewlogic VHDL into the scrap bin and 
ponied up the considerable sum (around $50k) for Synopsys tools because we 
were having so much trouble with the Viewlogic tools. The Viewlogic reps were 
not in the least suprised when we told them what we were doing and in fact 
proceeded to tell us how well their simulation tools integrated with Synopsys.

So, as the saying goes, "you get what you pay for". The Viewlogic tools cost 
about 60% of what Synopsys costs but we lost far more than that in lost 
productivity and missed deadlines.
Article: 4387
Subject: Re: VHDL for Xilinx designs?
From: "J.Mawer" <j.mawer@shef.ac.uk>
Date: Wed, 23 Oct 1996 10:37:11 +0100
Links: << >>  << T >>  << A >>
Andreas Wehr wrote:
> >Second is controlability.  It is much harder to floorplan an HDL design.
> >Much harder...  I find that floorplanning is the real key to resource
> >utilization and speed, especially for FPGAs.
> 
> HDL has nothing to do with floorplanning, you have to floorplan a schematic
> and a HDL design.

The statement was that it was easier to floorplan using schematic than
HDL I
for think that to be true.  Certainly it needs 



> >and require very little library work to add a new device. You
> >may save time writing with HDL up front, but if it is for a fast/dense
> >design, you will spend a great amount of time massaging it, rewriting it,
> 
> Why? When the counter will get bigger i have to change only a generic .
> Is this a great amount?
> 
> >I have some clients who I told them they would only have to pay me what I
> >save them.  For one, I converted their VHDL to schematics, went down two
> >part sizes, and two speed grades, saving $46 per board, and the volume is
> >in the thousands!
> 
> I bet, optimization of the VHDL to better VHDL had saved more than $46!

Personally I belive that for many instances schematic is at least as
good as
a HDL.  I tend to think that your above statement would loose you your
money!
Given that you know nothing about either a) the design or b) the parts
used.

Surley the thing about HDLs is that they are, largely, device
independent and
allow short development times (particulaly if a good library is used). 
This
gives rapid time to market -> more money for company.  Going in and
doing 
optimisations later be it using HDL or schematic can save you
significant costs
as shown above. But if the market hadn't been captured initially these
saving
might be worth nothing as there may no longer be a market.  This is why
the
interlectual property (IP) market is taking off.  It should however be
noted
with respect to this that many IP vendors provide different HDL models
for
a) different target technologies and b) different synthesis tools.  The
reason?
Because HDLs have to be written taking into account both these facts to
produce
optimal results.

It's very easy state that HDLs are great for everything and I tend to
agree they
are essential for lots of things, but don't fall into the trap of
beliving that
they produce excellent results with no effort.  Schematic still has
advantages in
the hands of a skilled engineers in some applications. I usually find it
easier
to visulise things in schematic rather than text but I'd rather design
large state
machines in a HDL.  

I'm sitting here designing full custom layout at the moment I would
challenge anyone
to produce faster more compact designs using soley a HDL.  I would also
challenge
anyone to design a 1 million transistor chip (in a sensible time frame!
that works
first time.  It's horses for courses.  It's somwhat nieve to claim that
any one
technique is the answer to all your problems

Furthermore remember VHDL isn't the only HDL.  Most asic vendors use
verilog as
they're golden simulator, those which sign off in VHDL often convert to
verilog and
simulate with say Cadence verilog XL before they will fab a device. 
VHDL does
however seem to be the HDL of choice for FPGAs


John
Article: 4388
Subject: Re: Xilinx xchecker.exe and Windows NT
From: Geir Ertzaas <ge@tandberg.no>
Date: Wed, 23 Oct 1996 14:31:49 +0200
Links: << >>  << T >>  << A >>
Thanks for the updated techdoc reference. I had almost given up on 
NT 4.0 and XACT.

I must admit that Xilinx seems to be very slow in making an NT release
when most of the EDA industry seems to be rushing towards NT with open
arms.

David Dye wrote:
> 
> Actually there is a much more complete solution found in the Xilinx
> Solutions Database:
> http://www.xilinx.com/techdocs/902.htm
> 
> There are more steps to be done than just installing the Rainport
> driver.  Following
> these steps should get people running with the DOS version (5.2.1) of
> the XACTstep
> software in either Windows NT 3.51 or 4.0.

This solution worked fine for me using NT 4.0 and XACT 5.2.1. A
few things are still not working - most annoyingly - xde refuses to load
a design. It starts up but crashes while reading the design file, it
actually crashes the display adapter driver(and thus NT) if I specify a
vesa graphics mode. Of course few of the windows tools do anything
useful, which was as expected...

One thing puzzled me though - xdelay and makebits uses almost 3 minutes
each to process a small 5202 design. In dos or windows 95 it only took 
a few seconds(<10) to run the same design through those tools.
(my machine is a 166 pentium w/32M ram)

In fact 2/3's of the total run time for this little design was spent in
those two tools??.

> 
> david.
> 
> David Dye
> Technical Applications Engineer
> Xilinx, Inc., San Jose, CA
> ph> (408) 879-5370
> email> david.dye@xilinx.com


Geir Ertzaas		|	email: ge@tandberg.no
Dev. Engineer		|	phone: +47 67 11 62 88
Tandberg Television AS	|
Ph. Pedersensv. 20	|
N-1324 Lysaker		|
Norway			|
Article: 4389
Subject: Re: VHDL for Xilinx designs?
From: kenneth.a.becker@att.com (Kenneth A. Becker)
Date: Wed, 23 Oct 1996 13:39:48 GMT
Links: << >>  << T >>  << A >>
tim_hubberstey@mindlink.bc.ca (Tim Hubberstey) wrote:

>
>I'm sorry but I have to speak up here. Viewlogic _does_ allow you to mix HDL 
>and schematic but their VHDL compiler is so bad that I can't recommend using 
>it to anyone. We recently tossed our Viewlogic VHDL into the scrap bin and 
>ponied up the considerable sum (around $50k) for Synopsys tools because we 
>were having so much trouble with the Viewlogic tools. The Viewlogic reps were 
>not in the least suprised when we told them what we were doing and in fact 
>proceeded to tell us how well their simulation tools integrated with Synopsys.
>
>So, as the saying goes, "you get what you pay for". The Viewlogic tools cost 
>about 60% of what Synopsys costs but we lost far more than that in lost 
>productivity and missed deadlines.

I'm going to concur with Tim here. In fact, I've got some stronger
statements about the whole process.

I've done programming with ORCA as well as Xilinx parts. I recently
(some 8 months ago) finished off a major project using VHDL tools
under Mentor Graphics and Synopsys. The designs were fairly complex
state machines with tons of random logic and 50-60 VHDL files apiece.
I was underwhelmed  with the process of design, simulation, and
production. Possibly because I was stuck with fixing a complex design
left in the lurch by another developer it took an exceedingly long
time to get the parts working properly. However, there were tools
issues that just blew me away on just >>how bad<< they were.

Synopsys.  I found that the tool and hierarchical VHDL minimization
did not get along well at all. The design I had was running at a
relatively high speed. If one minimized the individual VHDL
subcircuits in Synopsys, Synopsys and the ORCA libraries insisted upon
sticking additional buffers in between the the various hierarchies in
the design - yeah, back to back inverters on leads with one load. This
did the timing no good. Sometimes it would go so far as to use the
inverted signal to drive other CLBs, making it impossible to fix by
hand routing/renaming the offending leads in NeoCAD. The eventual
solution was to forget about minimizing the individual logic blocks,
but rather flatten the whole design and minimizing it in one stroke.
Since the minimization routines use random numbers to drive the
process, each compile was a crap shoot as to whether that design,
after place and route in NeoCAD, would have good timing. Remember that
I said that it was a complex design? How about three-day run times?
Pretty sad when you're on the critical path for a project. And I
wasn't anywhere near 80% fill.

In a previous life I designed a few Xilinx parts directly using XACT.
NeoCAD's interface to the ORCA (and, as far as I know, to Xilinx
parts) looks much the same.  It isn't standard, but it is direct; if
one wants a low prop delay on a lead, one can put it there. If I had
had the whole above mess to do over again, I would probably have done
it directly in NeoCAD. It would have taken me longer to get the
initial design phase done; on the other hand, I wouldn't be staring at
30-hour place and route times every time a bug got fixed. (And
>>that<< was on a SPARC 20!).

My considered opinion is that the Synopsys tool I used at the time was
highly optimized for custom VLSI and less so for CLB-based FPGA's. I
believe that for nice, regular structures (interrupt registers; data
flow paths, etc) and small designs these tools can do a good job; but
for serious logic garbage collection and multiple complex state
machines staying away from VHDL and using a >>good<< schematic editor
(directly into the CLB's, of course) or a low level editor like XACT
or NeoCAD may be a better way to go.

Of course this all falls flat on its face if one is planning to go,
after an initial debug/production run, to custom logic. There (from
the advertising/propaganda I've heard) VHDL seems to have a better
chance.


			Ken Becker
			Lucent Technologies

Article: 4390
Subject: Re: VHDL for Xilinx designs?
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 23 Oct 1996 14:57:22 GMT
Links: << >>  << T >>  << A >>
>I'm sorry but I have to speak up here. Viewlogic _does_ allow you to mix
HDL 
>and schematic but their VHDL compiler is so bad that I can't recommend
using 
>it to anyone.

I'm not recommending the Viewlogic VHDL tools, at least the old stuff for
FPGA development...you're right, it didn't work for FPGA's well at all. 
But none the less, you can still use any VHDL compiler (or any HDL
compiler) that outputs a .xnf file to add HDL to your Viewdraw FPGA
schematics.

Viewlogic has a real good simulation environment, and if you use their VHDL
for functional models (like a PCI bus transactor, DRAM etc., external to
the chip support circuitry) it integrates very well into their
schematic/simulation environment.

Viewlogic does have a new VHDL compiler out specifically for FPGAs. 
Exemplar does too... so do a few other companies.  I agree, Synopsys has
been the best to date, but my guess is you don't have to spend Synopsys's
greedy 50k for a halfway decent VHDL for FPGAs now.  I have the Exemplar
tools, and they are not bad, I would put them on par with the Synopsys
tools, and they are only 3.5k.

Austin Franklin
darkroom@ix.netcom.com
Article: 4391
Subject: Re: VHDL for Xilinx designs?
From: wehr@mikro.uni-stuttgart.de (Andreas Wehr)
Date: 23 Oct 1996 15:13:11 GMT
Links: << >>  << T >>  << A >>
Hi,

In article 207079c0@drt1, "Austin Franklin" <darkroom@ix.netcom.com> writes:

>I have seen HDL code that should have been reduced to simple logic take up
>half of a chip...and it has taken weeks for the designer to figure out how
>to, if it can be done at all, get the synthesizer to generate 'good'
>(subjective) code.


some time ago I had the same problem (garbage in garbage out), 
but since I use some guide lines (from great HDL books) how to 
describe state machines, counter, muxes...with HDL, the problem is gone away. 

>True in most cases.  The problem is since FPGAs are a course grained
>architecture, and have special device dependent features, what you have
>written to take advantage of one FPGAs architecture, may cause you problems
>with another.  I have never known of anyone, my self included, who has been
>able to easily migrate from one technology to another using an HDL. 
>Luckily, 99% of designs never really do...

In less than 1% of your designs migrate from an FPGA to an ASIC?
 
>> I bet, optimization of the VHDL to better VHDL had saved more than $46!
>
>May be I should have sent the job to you and we could have split the
>difference!

>Not for FPGAs.  Given todays VHDL compilers, (my experience is with
>Viewlogic, Synopsis and Exemplar VHDL compilers for FPGAs), not one of them
>is nearly as good as a schematic can be for best speed and resource
>utilization.  VHDL is good if you don't care how big your part is, and if
>you have a lower speed design.  I am using it for two clients now, and they
>are happy with this restriction.  I have two clients that if the design
>were done in VHDL, the design wouldn't work.

My opinion is that a new revision or redesigns is done much more easier with VHDL
or Verilog than with a schematic.

Personally I use HDLs and I hope all competitors use schematics and they are 
happy with it. ;-)


best regards,

Andreas 


Article: 4392
Subject: Re: VHDL for Xilinx designs?
From: brenes@c2t.com (Erasmo Brenes)
Date: Wed, 23 Oct 1996 18:15:35 GMT
Links: << >>  << T >>  << A >>
In article <01bbbed7$2597ebe0$2da8b8cd@drt1> "Austin Franklin" <darkroom@ix.netcom.com> writes:
>A number of problems exist with HDLs in general.  One is you don't know
>exactly what the code is going to compile down to...  Kind of like the

Yes you do. It is deterministic. Specially if you do know how to code in
VHDL, and the differences between each of the constructs.

>proccessors with lots of memory (ASICs), but for a small slow micro (FPGAs)
>it's not as good.  In an HDL, a case statement can become this really obese
>thing checking for every possible condition for each branch...

Not if you know how to code the case statement. Sometimes, the best approach
is to have a combination of IF statements with embedded case statements 
which the compiler can optimize. Also, you can use the '-' for don't
care, except that not all simulators know how to handle it.

>  I certainly
>believe you can do pretty well with some finely crafted HDL code, if you
>know exactly what it is going to compile down to.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Agreed, and that is my entire point. See below.

>
>Second is controlability.  It is much harder to floorplan an HDL design. 
>Much harder...  I find that floorplanning is the real key to resource
>utilization and speed, especially for FPGAs.

Floorplanning is needed independent of the design entry method. If you want to
be efficient, then you have to floorplan. Period. If your VHDL code is done
in a hierarchical manner, then floorplaning is rather trivial, as you can
place the blocks one at a time. If on the other hand, you have a flat one
process-does-all code, or a collection of concurrent statements, ala min-term
form, then I would expect the same level of difficultiness in floorplaning
that you would have if it had been done in a flat schematic entry.

>
>Personally, I like to mix both...but schematics is really the way to go for
>the best speed and resource utilization.  I do schematics with my own

I disagree. For example, we had an engineer work in a design which he 
designed in schematic form. He selected a XC4010 which he hand placed, and
hand routed(yeah, he was an idiot). The design contained a 16x16 ram file,
a 32x16 ROM look-up table, 6 16 bit timers, 4 8 bit timers, and master/slave
interfaces to two busses, one of them VME, the second an i960 bus. Bottom
line is that I looked at the schematic, laughed at it, since once it
was downloaded into the Xistink, it wouldn't run and crashed the i960 and
VME. Instead of fixing a screwed up schematic, I coded the entire thing
in VHDL. Under this scenario, I had fixed pins to deal with, since the
design was already built. I was able to simulate, not only the Xistink, but
the entire board in our VHDL simulator, debug my code, synthesize it and
have it running in 4 days. In addition, it fit, operated at higher frequency
than the original designer had accomplished, and added some functionality
which was missing from the original design. Now, our company has a VHDL
code description of the design, which other engineers can read and under-
stand without a painful search through 14 pages of schematics, and when
we go through a re-spin of the PCB, I'll float the pins and let the
floorplanning be even better, with a definite improvement in speed and
better utilization of the CLBs (for instance, the timers couldn't be
CLA because of the original pin assignments forced a massive routing
crossing). BTW, the original designer is no longer with us, and he
had claimed to be a Xilinx guru, which even the local Xilinx FAE
concurred. :-)

>libraries of n bit registers, tbufs, counters, muxes.  They are device
>independent, and require very little library work to add a new device. You

The code on the above example can be retargetted to any FPGA, either ALTERA,
ACTEL, or ORCA, without any recoding other than the ROM block, which is
a minor submodule.

>I have some clients who I told them they would only have to pay me what I
>save them.  For one, I converted their VHDL to schematics, went down two
>part sizes, and two speed grades, saving $46 per board, and the volume is
>in the thousands!

I bet you that it was rather trivial to convert the VHDL to schematic. In
addition, if you indeed saved that much space and size, then I would have
to say that the original VHDL code was poor and the designer didn't know
the task in hand nor the VHDL environment. Also, the quality of the
synthesis affects the utilitization of the FPGA. Not all VHDL compilers
are created equal. I spent months benchmarking all of the
VHDL compilers out there. In the end, we settled for Exemplar, which
beat all of the others in our benchmarks. In that lapse of time, I saw
three revisions of Viewlogic (both on PCs and Sun workstations), Synario,
Synplicity, Warped, other re-encarnations of Metamore VHDL compiler, and
two revs of Exemplar Galileo. Our company also has a Synopsis design
environment for ASIC development, so we have the cadillac, so they say :-).
Before I designed a 175K gates ASIC, I was a schematic kind of guy, but
since then I've seen the light :-).

Hope this posting balances the discussion.

Erasmo
Article: 4393
Subject: Mentor B.2 and XACT 5.2.1 ?
From: Lance Gin <c43lyg@dso.hac.com>
Date: Wed, 23 Oct 1996 11:53:58 -0700
Links: << >>  << T >>  << A >>
Fellow Mentor/Xilinx users,

Has anyone been using B.2 with the Xilinx XACT 5.2.1 design kit?
We're currently at A.4 and are contemplating a move to B.2. This would
allow us to take advantage of Autologic II's improved Xilinx synth 
capabilities in our mixed VHDL/schematic process. I'm curious if B.2
schematics present a problem for XACT?

The Xilinx line apparently is that only A.4 is "officially" supported,
although I'm aware of some Xilinx engineers who are using B.1 internally.

Thanks in advance,


-- 
_______________________________________________________________________

Lance Gin                                         "off the keyboard
Delco Systems - GM Hughes Electronics              over the bridge,
OFC: 805.961.7567  FAX: 805.961.7739               through the gateway,
C43LYG@dso.hac.com                                 nothing but NET!"
_______________________________________________________________________
Article: 4394
Subject: Suggestions for inexpensive FPGA EVM (new and used)?
From: "Andrew Plumb" <Tekmage@io.org>
Date: 23 Oct 1996 19:49:12 GMT
Links: << >>  << T >>  << A >>
Hello All,

What suggestions do people have out there for a starter FPGA development
kit/EVM/EVB?  Ideally, I'd like something that I can program FPGA ICs to
use in future single-chip designs.  Being a student means I can't afford
anything big.  I just want something to play and discover with.

Any donations of old equipment will be accepted with pleasure. :-)

Andrew.

--

Andrew Plumb, VE3SLG.
E-mail:  Tekmage@io.org
	 3app@qlink.queensu.ca
WWW:  http://www.io.org/~tekmage/

Traversing digital oceans astride an analog dolphin...
Article: 4395
Subject: Re: VHDL for Xilinx designs?
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 23 Oct 1996 22:15:11 GMT
Links: << >>  << T >>  << A >>
> Yes you do. It is deterministic. Specially if you do know how to code in
> VHDL, and the differences between each of the constructs.

I agree it is deterministic, meaning it will compile down to the same logic
every time if given the SAME inputs....but...how do you know what that
logic is going to be?  Different compilers compile down to different logic.
 Since you don't know what it is going to compile down to, you don't know
if it's good or bad...With a schematic, what you see is what you get...

> Not if you know how to code the case statement. Sometimes, the best
approach
> is to have a combination of IF statements with embedded case statements 
> which the compiler can optimize. Also, you can use the '-' for don't
> care, except that not all simulators know how to handle it.

I agree too.  But how do you know what the compiler is going to do with the
case statement, since different compilers will generate different results
with the same VHDL code...

> Floorplanning is needed independent of the design entry method.

Agreed, but with VHDL, you don't get intellegible names out of the code. 
Also, when you change the design, the names change too.  At least that's
the experience I have had.  There is a way around that....and when we do
VHDL for designs, or our clients do, we do the design so it will give us
consistent naming.

> >Personally, I like to mix both...but schematics is really the way to go
for
> >the best speed and resource utilization.
> 
> I disagree. For example, we had an engineer work in a design which he 
> designed in schematic form. He selected a XC4010 which he hand placed,
and
> hand routed(yeah, he was an idiot). The design contained a 16x16 ram
file,
> a 32x16 ROM look-up table, 6 16 bit timers, 4 8 bit timers, and
master/slave
> interfaces to two busses, one of them VME, the second an i960 bus. Bottom
> line is that I looked at the schematic, laughed at it, since once it
> was downloaded into the Xistink, it wouldn't run and crashed the i960 and
> VME. Instead of fixing a screwed up schematic, I coded the entire thing
> in VHDL. Under this scenario, I had fixed pins to deal with, since the
> design was already built. I was able to simulate, not only the Xistink,
but
> the entire board in our VHDL simulator, debug my code, synthesize it and
> have it running in 4 days. In addition, it fit, operated at higher
frequency
> than the original designer had accomplished, and added some functionality
> which was missing from the original design. Now, our company has a VHDL
> code description of the design, which other engineers can read and under-
> stand without a painful search through 14 pages of schematics, and when
> we go through a re-spin of the PCB, I'll float the pins and let the
> floorplanning be even better, with a definite improvement in speed and
> better utilization of the CLBs (for instance, the timers couldn't be
> CLA because of the original pin assignments forced a massive routing
> crossing). BTW, the original designer is no longer with us, and he
> had claimed to be a Xilinx guru, which even the local Xilinx FAE
> concurred. :-)

There are a lot of self proclaimed Xilinx gurus out there, and self
proclaimed gurus in general, but a bad engineer, with any tool, VHDL or
schematic, is going to get bad results.  I spend half my life cleaning up
other peoples bad engineering, and the other half doing what I believe to
be good engineering from scratch (I don't get much sleep...).  The real
truth is you have to know the device and the tools in order to do a good
job.  BTW, who was this guru? (email, not in group please)

 >Also, the quality of the
> synthesis affects the utilitization of the FPGA. Not all VHDL compilers
> are created equal.

Agreed, 

>I spent months benchmarking all of the
> VHDL compilers out there. In the end, we settled for Exemplar, which
> beat all of the others in our benchmarks. In that lapse of time, I saw
> three revisions of Viewlogic (both on PCs and Sun workstations), Synario,
> Synplicity, Warped, other re-encarnations of Metamore VHDL compiler, and
> two revs of Exemplar Galileo. Our company also has a Synopsis design
> environment for ASIC development, so we have the cadillac, so they say
:-).
> Before I designed a 175K gates ASIC, I was a schematic kind of guy, but
> since then I've seen the light :-).

Glad to hear that, I just got the Galileo tools, and look forward to trying
them.  I have Synopsys too, and that has been the best so far....I get my
tools free cause I do work for some of these EDA and ASIC companies...but
the high price of Synopsys has been very prohibitive to most people.  The
Exemplar tools seem to be more reasonably priced.  P.S. - don't get
blinded! (sic)

I do agree that good design and understanding, whether using VHDL or
schematics, or whatever, will lead to better results.  The tools for VHDL
for FPGAs have been pretty poor until recently.  The EDA vendors have done
a good job making their tools work with FPGAs recently.  I do believe that
today, you can do a pretty good (near minimum resource utilization, and
somewhat fast timing) design with VHDL.  Previously, VHDL used to cap out
at 10Mhz (in a Xilinx 4k).  Today, because of better VHDL compilers, and
faster parts, you can get 25+Mhz out of it.  I still don't think, nor have
I seen, anyone be able to get near 33Mhz out of VHDL in a Xilinx 4k FPGA.

I also think that data path in schematics (there is no optimization in data
path...) is far better than in VHDL because you can see it.  You don't have
to sift through pages and pages of code to figure it out.

This appears to have been the liveliest discussion in this
newsgroup....It's like the Mac is better than PC thing....

Austin Franklin
darkroom@ix.netcom.com

Article: 4396
Subject: Re: VHDL for Xilinx designs?
From: tim_hubberstey@mindlink.bc.ca (Tim Hubberstey)
Date: Thu, 24 Oct 1996 04:24:48 GMT
Links: << >>  << T >>  << A >>
In article <01bbc0f2$ad72c860$76c220cc@drt1> "Austin Franklin" <darkroom@ix.netcom.com> writes:
>From: "Austin Franklin" <darkroom@ix.netcom.com>
>Subject: Re: VHDL for Xilinx designs?
>Date: 23 Oct 1996 14:57:22 GMT

>>I'm sorry but I have to speak up here. Viewlogic _does_ allow you to mix
>HDL 
>>and schematic but their VHDL compiler is so bad that I can't recommend
>using 
>>it to anyone.

[snip]

>Viewlogic does have a new VHDL compiler out specifically for FPGAs. 
>Exemplar does too... so do a few other companies.  I agree, Synopsys has
>been the best to date, but my guess is you don't have to spend Synopsys's
>greedy 50k for a halfway decent VHDL for FPGAs now.  I have the Exemplar
>tools, and they are not bad, I would put them on par with the Synopsys
>tools, and they are only 3.5k.

>Austin Franklin
>darkroom@ix.netcom.com

We _were_ using the latest Viewlogic synthesizer, v6.0.3 under Unix and while 
it is a vast improvement over the previous (nearly unusable) v5.3 stuff, it is 
still a far cry from being a serious tool.
Article: 4397
Subject: Re: Has anyone ever used a C -> Xilinx netlister?
From: "Jan Gray" <jsgray@acm.org>
Date: 24 Oct 1996 05:07:02 GMT
Links: << >>  << T >>  << A >>
Austin Franklin <darkroom@ix.netcom.com> wrote in article
<01bbbefd$7414e3b0$a1cab7c7@drt1>...
> There are two C -> Xilinx netlisters I know of, and I am curious if
anyone
> has any experience with them, or any others.
> 
> The first I know of is called NLC, developed by Christian Iseli at the
> System Logic Lab of the Federal Polytechnical School of Lausanne,
> Switzerland.  The second I know of was developed by the networking group
of
> Digital in California.
> 
> Thanks,
> 
> Austin Franklin
> darkroom@ix.netcom.com

Certainly Digital has one.

I have my own tool, called CNets, which emits XC4000 XNF.  It is a set of
classes which extend C++ with user defined types to describe nets, buses
(vector of nets), and gate expressions.  There are also functions to emit
primitives such as flip-flops, SRAMs, TBUFs, IBUFs, etc.  My processor
designs are specified in CNets.

I wrote CNets for three reasons.
* I was growing old drawing and labeling 32-bit datapath elements in
ViewLogic
* the DOS WorkView tools didn't seem to work very well under Win95 or NT,
and I loathe DOS
* I couldn't afford Verilog or VHDL tools, and neither could other people
(computer engineering hobbyists) with whom I wish(ed) to share my tools

In retrospect, and particularly in light of recent discussions about doing
Xilinx designs using VHDL, CNets, though primitive, has turned out to be
quite a pleasant design environment -- the best of both worlds.

Like schematic capture, all primitive instantiations, placements, and other
constraints, are explicit (if you wish).  No "pushing on a rope" to get the
design you have in mind through the HDL synthesis tool.  Floorplanning
datapaths is a breeze.  And since I tend to do my own "mental technology
mapping" (of gates into LUTs), by default CNets automatically emits FMAPs
for 2-4 input logic functions.

Like HDLs, CNets is based on a programming language, therefore it is easy
to have functions, loops, conditionals, variable-width structures,
lookup-tables, conditional emission of logic, etc.  Best of all, CNets
designs recompile, relink, run, and emit the new XNF, ready for place and
route, in less than ten seconds.  Wait another 30 minutes for PPR and
you're done. :-)  Also, for users familiar with C++, CNets should be more
familiar than Verilog or VHDL.

To give you a feel for CNets, attached below are some examples of code from
one of my designs.  Keep in mind this was a first cut, a quick hack, to get
my darn designs going.

This past summer I started CNets, version 2, in Java -- "JHDL" if you will.
 Key new features included better support for design 'modules' and a
cycle-based simulator.  Unfortunately, I didn't finish this project.  I may
yet try again this fall in my copious spare time.

Cheers,

Jan Gray
Redmond, WA



lfsr_div emits lfsr counters to divide by arbitrary n.  It is similar to an
XBLOX counter with style LFSR.  The first half of the function determines
how many bits are in 'n', what the lfsr shift register bits 'w' look like
after 'n' clockings.  The second half of the function actually emits an
n-bit shift register, whose input is the xnor of certain taps off the shift
register.  The formal arguments are
	out -- the net which is true after n clockings of the LFSR counter
	ce -- the counter clock enable
	reset -- if true, reset the counter on next clock edge
	n -- the divisor

// emit an lfsr counter and decoder to divide by n
//
// See "Efficient Shift Registers, LFSR Counters, and
// Long Pseudo-Random Sequence Generators", Peter Alfke,
// Xilinx App Note, Aug. 1995
//
void lfsr_div(Net out, Net ce, Net reset, unsigned n) {
	Env e;
	e.setModule(out.getName());

	// choose appropriate width counter
	static unsigned taps[32][4] = {
		{ 0 }, { 0 }, { 0 }, { 3, 2 },
		{ 4, 3 }, { 5, 3 },	{ 6, 5 }, { 7, 6 },
		{ 8, 6, 5, 4 }, { 9, 5 }, { 10, 7 }, { 11, 9 },
		{ 12, 6, 4, 1 }, { 13, 4, 3, 1 }, { 14, 5, 3, 1 }, { 15, 14 },
		{ 16, 15, 13, 4 }, { 17, 14 }, { 18, 11 }, { 19, 6, 2, 1 },
		{ 20, 17 }, { 21, 19 }, { 22, 21 }, { 23, 18 },
		{ 24, 23, 22, 17 }, { 25, 22 }, { 26, 6, 2, 1 }, { 27, 5, 2, 1 },
		{ 28, 25 }, { 29, 27 }, { 30, 6, 4, 1, }, { 31, 28 }
	};
	check(n <= (1 << 30));
	for (unsigned bits = 1; n >= (1U << bits); bits++)
		;
	check((1U << (bits-1)) <= n && n < (1U << bits));

	// determine bit pattern of terminal state (after n-1 clockings of lfsr)
	unsigned w = 0;
	for (unsigned i = 1; i < n; i++) {
		unsigned in = 0;
		for (unsigned j = 0; j < 4 && taps[bits][j]; j++)
			in ^= (w >> (taps[bits][j]) - 1) & 1;
		w = ((w << 1) & ((1 << bits) - 1)) ^ !in;
		check(w != 0);
	}

	// emit shift register and gates to compare to terminal state
	bus(lfsr, bits+1);
	out = lfsr(bits,1) == w;
	lfsr[0] = gnd;
	net(lfsr_in) = xnor(lfsr[taps[bits][0]], lfsr[taps[bits][1]],
lfsr[taps[bits][2]], lfsr[taps[bits][3]]);
	net(lfsr_reset) = out | reset;
	ff(lfsr[1], lfsr_in & ~lfsr_reset, ce);
	for (i = 2; i <= bits; i++)
		ff(lfsr[i], lfsr[i-1] & ~lfsr_reset, ce);
}
		
Some of the trickier constructions:

 out = lfsr(bits,1) == w;
  -- drive 'out' with an AND gate which is true when the bits lfsr[bits:1]
match the bit pattern in the integer 'constant' w.
	
 net(lfsr_in) = xnor(lfsr[taps[bits][0]], lfsr[taps[bits][1]],
lfsr[taps[bits][2]], lfsr[taps[bits][3]]);
  -- drive <out>/lfsr_in with the XNOR of up to four taps off the shift
register.

 ff(lfsr[i], lfsr[i-1] & ~lfsr_reset, ce);
  -- emit a flip-flop whose D input is the AND of lfsr[i-1] and NOT
lfsr_reset, whose clock enable is 'ce', whose Q output is lfsr[i].



This next piece of code defines a 'cbit'-bit pipelined RISC datapath. 
Sorry for the sparse comments.  This is *not* what I would consider
production code!  You may wish to visit
http://www3.sympatico.ca/jsgray/sld020.htm to see what this does.
....
for (i = 0; i < cbit; i++) {
	unsigned r = rowForBit(i);
	unsigned t = 1 + even(i);

	// instruction register
	ff(ir[i], mem.d[i], c.irce, _, loc(r,colIR));

	// PC incrementer and MAR (memory address register)
	m2(marmux[i], pcincr[i], adder[i], c.addersel, loc(r,colMMAR));

	if (i >= 2)
		ff(pc[i], marmux[i], c.pcce, _, loc(r,colPC));
	ff(mem.ad[i], marmux[i], c.marce, _, loc(r,colMAR));
	tbuf(res[i], pc[i], c.pct, tloc(r,colPCT,t));
	if (i >= 2 && even(i))
		inc2(pcincr[i+1], pcincr[i], pccin[i+2], pccin[i+1], pc[i+1], pc[i],
pccin[i], loc(r,colPCIncr));

	// result bus and write back
	ff(wb[i], res[i], c.wbce, _, loc(r,colWB));

	// register file, A and B operand buses
	ram(rfa[i], wb[i], c.rna, c.awe, loc(r, colRFA+odd(i)));
	m2(ma[i], rfa[i], res[i], c.forward, loc(r,colMA));
	ff(a[i], ma[i], c.ace, _, loc(r,colA));
	ram(rfb[i], wb[i], c.rnb, c.bwe, loc(r, colRFB+odd(i)));
	ff(dout[i], rfb[i], c.doutce, _, loc(r, colRFB+odd(i)));
	m2(mb[i], rfb[i], ir[i<cbitImm ? i : cbitImm-1], c.immed, loc(r,colMB));
	ff(b[i], mb[i], c.bce, _, loc(r,colB));

	// ALU
	if (even(i))
		addsub2(adder[i+1], adder[i], cin[i+2], cin[i+1], a[i+1], a[i], b[i+1],
b[i], cin[i], c.add, loc(r,colAdder));
	tbuf(res[i], adder[i], c.addert, tloc(r,colAdderT,t));
	::lu(lu[i], a[i], b[i], c.lu1, c.lu0, loc(r,colLU));
	tbuf(res[i], lu[i], c.lut, tloc(r,colLUT,t));

	// shifter: shift/rotate left and right 1, 2, and 4 bits
//	tbuf(res[i], (i >= 4)     ? a[i-4] : rola[cbit-4+i], c.shl4t,
tloc(r,colShiftT  ,t));
	tbuf(res[i], (i >= 2)     ? a[i-2] : rola[cbit-2+i], c.shl2t,
tloc(r,colShiftT  ,t));
	tbuf(res[i], (i >= 1)     ? a[i-1] : rola[cbit-1+i], c.shl1t,
tloc(r,colShiftT+1,t));
	tbuf(res[i], (i < cbit-1) ? a[i+1] : rora[1-cbit+i], c.shr1t,
tloc(r,colShiftT+2,t));
	tbuf(res[i], (i < cbit-2) ? a[i+2] : rora[2-cbit+i], c.shr2t,
tloc(r,colShiftT+3,t));
//	tbuf(res[i], (i < cbit-4) ? a[i+4] : rora[4-cbit+i], c.shr4t,
tloc(r,colShiftT+5,t));

	// data in
	tbuf(res[i], mem.d[i], (i < 8) ? c.dinbytet : (i < 16) ? c.dinhalft :
c.dinwordt, tloc(r,colDinT,t));
	// zero/sign extension
	if (i < 8)
		;
	else if (i < 16)
		tbuf(res[i], c.halfsex, c.halfsext, tloc(r,colExtT,t));
	else
		tbuf(res[i], c.wordsex, c.wordsext, tloc(r,colExtT,t));

	// data out
	tbuf(res[i], dout[i], c.doutt, tloc(r,colDoutT,t));
	tbuf(mem.d[i], res[i], (i < 8) ? mem.doutbytet : (i < 16) ? mem.douthalft
: mem.doutwordt, tloc(r,colDBusDoutT,t));
}

Things to note here.
* c.XXX are control signals from the "control unit" module
* mem.XXX are memory datapath signals from the "on-chip memory bus" module
* some elements are commented out -- try commenting out parts of your
schematic sometime.
* constraints -- the optional calls to 'loc()' and 'tloc()' apply placement
constraints, forcing elements to certain (row,col) positions; the various
colXXX are just enum constants, so it is easy to refloorplan things; note
no rloc()s yet!

Article: 4398
Subject: Re: VHDL for Xilinx designs?
From: smsasaki@loop.com (SM Sasaki)
Date: Thu, 24 Oct 96 05:23:11 GMT
Links: << >>  << T >>  << A >>
In article <01bbc02a$7f96cf90$207079c0@drt1>, "Austin Franklin" <darkroom@ix.netcom.com> wrote:
>> I seem to remember that the old DOS Viewlogic (unrestricted edition
>> was $28000 here in the UK) had the ability to mix schematic and VHDL
>> entry ...


Data IO offers a product called Synario that runs under Windows.  It is an 
integrated environment that will allow you to target a number of FPGA/EPLD's 
including Xilinx.  It will allow you to mix schematic, VHDL, ABEL and 
graphical state machine entry.  If you do include VHDL input, you are 
restricted to using a VHDL simulator; otherwise you can choose between Verilog 
and VHDL simulation (both functional and timing).
Article: 4399
Subject: Integer Multiplier
From: tendy the <tthe@aesprodata.com.au>
Date: Thu, 24 Oct 1996 17:13:55 +0800
Links: << >>  << T >>  << A >>
Dear all,

Could any one please advise me about the most compact and fastest
implementation / algorithm of 16 bit-integer-multiplier. I intend to use
the Xilinx XC4000 series or the Altera Flex10K. Many thanks !

Regards
Tendy
ERG Telecommunications, Australia
tthe@aesprodata.com.au


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
2017JanFebMarApr2017

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