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 57225

Article: 57225
Subject: Re: Xilinx Webpack bugs bugs bugs
From: Thomas <tom3@protectedfromreality.com>
Date: Thu, 26 Jun 2003 04:51:50 GMT
Links: << >>  << T >>  << A >>
I read with interest your thoughts about hdl vs schematics and the parallel 
with software
I've developped software for 14 years and while at heart I agree with you, 
in my day to day practice I disagree. Assembler will always provide you a 
most optimized solution, but C/C++ is much faster to develop with and is 
more accessible; btw, that's assuming you have competent engineers writing 
assembler, otherwise it turns into a mess very quick. yes, you definetly 
lower the efficiency of the resource usage with a higher level language, 
but nowadays it is cheaper to get faster / bigger hardware than more 
engineers / time.
the days where we used to build things right are over; now the key is how 
fast you can put something on the market; it's sad, but the tech industry 
is not what it used to be.
I have never been too much in touch with the hardware industry, but lately 
it has changed and I realize that you guys have the exact same issues / 
concerns / problems / etc we have in software; kind of ironic, in a sad 
way.

Thomas.



On Wed, 25 Jun 2003 22:23:48 -0400, Patrick MacGregor 
<patrickmacgregor@comcast.net> wrote:

> Amen brother!
>
> The "pay" tools are essentially the same, and work just as deplorably.  I
> have a copy of ISE 5.2, and it uses the same sorry excuse for a schematic
> editor.  I invented the "hexplitive", which was swearing in base 16, when
> working with X schematic tools.
>
> Xilinx clearly has no interest in catering to the schematic entry crowd 
> and
> their tools show it.  Their schematic tools are about as good as 
> something
> like OrCad was --  OrCad from 15 years ago running under DOS that is.
>
> I have worked exclusively with Altera tools since the late '80s because
> their support for schematics was SO MUCH better.  There is simply no
> comparison.   I think that for most FPGA designs, X or A parts would work
> just fine.  However, the crap you have to go through to use X tools was
> never worth it.  Still isn't in my book.  Their tools can take a one day
> design and turn it into a week of rebooting and hair pulling.
>
> I also can't buy into the HDL argument.  The reason is simple.  If you 
> were
> a software developer and you needed your code to be as small as possible 
> and
> run as fast as possible, what language would you use?  Well, every 
> software
> developer I've ever met answers the same -- native assembly language for 
> the
> processor in question.  No compiled code will be more efficient because 
> of
> the layers of abstraction that higher level languages impose.  The 
> embedded
> developers I've worked with always got a good chuckle out of their C
> language counterparts sucking up 100's of kilobytes of memory compared to
> the few K that their assembly code needed.
>
> HDL is the same.  You abstract designs (so that non-designers can pretend 
> to
> be designers I suppose) and pay a penalty by having circuit bloat.  If 
> you
> want the smallest design possible, and want it to run as fast as 
> possible,
> you need to use the design equivalent of assembly coding -- i.e. 
> schematics.
> A picture is worth a thousand words, so you can make a picture or type a
> thousand words.  Which one will be easier for someone else to understand,
> hmm?
>
> I recently talked to an FAE for an FPGA vendor.  He said that fully 80% 
> of
> the designs he has seen are done in schematics.  You can even read about
> graphical versions of HDL coming out.  Sounds like schematics to me.  
> Except
> that you add a layer of obfuscation in there that will make for a more
> bloated design.  Why bother?
>
> An ironic thing to notice is that if you open many of the X design 
> examples
> included with the tools, you'll see that they are schematic based.
>
> With a schematic it is sooooo simple to identify each and every flop and 
> see
> what it is doing in a simulation.  Something isn't working in HDL?  Good
> luck.  Oh yeah, and with schematics, you never have to do all that 
> modeling
> nonsense.  While most "designers" are modeling what their circuit is
> supposed to do, I've already got it done, simulated, verified on the 
> bench,
> off my plate and onto the next thing.
>
> I was taught the power of schematics and their companion, the timing
> diagram, when I was a wee engineer pup.  My first boss would sit me down 
> and
> go over the schematics with me, asking me to justify each and every
> component on the page.  If there wasn't a good reason for it, it was 
> gone.
> Amongst the many invaluable lessons he taught me was that every component 
> in
> the circuit should have a reason.  Try doing that with an HDL 
> abstraction.
> Most "designers" haven't a clue how that hunk of code they wrote got
> implemented in actual gates.  Scott Adams would probably call them
> "Duhsigners".
>
> <getting off soapbox now>
>
> So, I'm with you 100%.  Schematics rule.  Xilinx has no reason whatsoever 
> to
> support schematics, as the bloated designs that HDLs produce force folks
> into buying larger, faster speed grade parts that are naturally  more
> costly.  Works for them.
>
> You can always download the free Altera tools and play with their stuff.
> Fully integrated schematic capture, compiler and simulator.  Very nice.  
> Not
> perfect or bug free, but then no tool is.  It is, however, VASTLY 
> superior
> to the X garbage schematic tools.
>
> When I need to design something in an X part, I do it first in the A 
> tools
> and use their native simulater.  Then I re-enter it in X.  Doing the
> drawings twice is STILL faster than doing the design from scratch in X.  
> Try
> it.
>
> I tend to always push my clients to use A parts simply because the tools 
> are
> so superior.  Design times are radically reduced, and that saves them
> tangible money.  If they insist on X parts, I revert to the paragraph 
> above.
>
> Don't buy into the HDL propaganda.  Schematics will never do you wrong.
>
>
>
>
>
>
> "Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
> news:bdcqge$jo5$1@sass2141.sandia.gov...
>> Hi:
>>
>> Here's a chronicle of today's headaches.
>>
>> 1.  ECS schematic editor can't deal with filenames that contain anything
>> except 0-9 a-z A-Z .
>>
>> 2.  I selected a large block of schematic, and when I tried to move it,
>> ECS said "Internal Error: Delete Branch"
>>
>> 3.  I guess nobody uses schematic entry because the editor is simply
>> impossible to use.  It is an absolute disaster.  I try to select a group
>> of objects to move, and it simply won't let me select them.  They don't
>> highlight.  I try to select everything I have drawn to move it, and I
>> get error mentioned in #2 above.  The autorouting is useless.  Get rid
>> of it.  Hint:  humans are smarter than computers.  Just let me draw my
>> own wires.
>>
>> 4.  Oh good grief, I moved some things, and then I simply cannot select
>> anything anymore.
>>
>> You see folks, when you make software this bad, even if it is free,
>> rather than making me want to pay for the "good" software, it makes me
>> think you simply can't write good software.  What evidence do I have
>> that if I pay for your non-free tools, that they will be any better?
>> None.  On the contrary, I have volumous evidence that I will simply be
>> paying for the exact same thing, only I will not only be frustrated, but
>> poorer.  The end result is the same.  I can't use your silicon.
>>
>> So perhaps I have made a big mistake.  Perhaps I should have gone with
>> Altera.  I just don't know now.
>>
>> Or perhaps analog design would be a way to avoid all this crap
>> altogether.  I don't seem to have much trouble with SPICE simulators.
>> Heck even Linear Technology's LTSpice *FREE* simulator is very useable.
>>
>> Argh!
>>
>>
>> 5.  I closed the schematic editor hoping that if I re-opened my file it
>> might reset som eof its internal data structures, and start working
>> again.  Now I try to reopen my schematic source from Project Navigator,
>> and nothing happens.  It simply sits there when I click "open".
>>
>> <Mr. Carlen strikes head with palm, to try to wake up from the bad 
>> dream.>
>>
>> Nope this is reality.  Bummer.
>>
>> Aha!  Project Navigator couldn't open my source because it didn't have
>> the same name that I created it with.  I created it as "cross32-52"
>> which Project Navigator accepted just fine.  But ECS wouldn't save the
>> file with this name, even though it opened it the first time.  So I
>> saved it as something else, which of course broke Project Navigator.
>> Well that's certainly my fault.  I should have expected ECS to not save
>> filenames with '-' characters.
>>
>> 6.  After closing everything an reopening, I can select and move things
>> in ECS again.  Oh joy!
>>
>> 7.  I wanted to start a new project to develop a modified version of a
>> previous design done from scratch in 5.2i.  I copied the .sch and .ucf
>> files to the new project dir.  I can edit the schematic, so I deleted
>> some stuff I didn't want in there.  Then I can't open the .ucf file
>> because it has nets that aren't in the schematic.  I don't know why in
>> the original project, when I would add or remove nets from the
>> schematic, the user constraints file was automatically updated to
>> reflect the nets in the schematic.  This doesn't work now, but perhaps
>> it's because there is some file missing.
>>
>> So I will remove the .ucf source and add a new one which I'll set up
>> from scratch.  I click "remove" and then I add a new source, a user
>> constraints with the same name as the one that isn't working.  Project
>> NAvigator prompts me if I want to overwrite the old file.  I click "Ok"
>> and expect that when I open the new .ucf file, it will be a reflection
>> of the nets in my schematic.
>>
>> No such luck, the broken .ucf was not everwritten, so it still complains
>> of errors of missing nets.
>>
>>
>> Well that's all before lunch time.  Let's see what happens this
> afternoon...
>>
>>
>> I guess if there's a point to all this, I should look around on Xilinx's
>> web site some more and find out where to report bugs.  But I have
>> reached a point with software in general where I am tired of doing this.
>> That is because, I often wind up spending hours reporting the bugs in
>> the rigorous detail that is needed if there is to be any hope of anyone
>> actually fixing them.  Unless of course, the software had been
>> rigorously tested in the first place.
>>
>>
>>
>> --
>> _______________________________________________________________________
>> Christopher R. Carlen
>> Principal Laser/Optical Technologist
>> Sandia National Laboratories CA USA
>> crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply.
>>
>
>
>



Article: 57226
Subject: Re: ERROR:iMPACT:583
From: "tk" <tokwok@hotmail.com>
Date: Thu, 26 Jun 2003 13:45:34 +0800
Links: << >>  << T >>  << A >>
I'm quite sure that the physical cable connection is ok

actually, the platform I use is ML300 and I try to program the xc2vp7 via
the
Parallel Cable IV. Does anyone have the experience on it ? Are there any
settings on the ML300 board I should pay attention to ?

Thanks in advance.

tk

"Neil Glenn Jacobson" <neil.jacobson@xilinx.com> wrote in message
news:3EF9F98F.30402@xilinx.com...
> iMPACT is telling you that you are getting all 0's back from the device
> when it is expecting the IDCODE.  Assuming the device is currently
> unprogrammed, I would first check your physical cable connections to the
> device making certain that the device itself and the cable are both
> properly powered
>
> This error does not appear to be related to the software
>
> tk wrote:
> > Hi all,
> >
> > I get the following error when I try to program xc2vp7 device using
iMPACT
> > (ISE 5.1i):
> >
> > ERROR:iMPACT:583 - '1': The idcode read from the device does not match
the
> > idcode in the bsdl File.
> > INFO:iMPACT:629 - '1':  Device IDCODE : 00000000000000000000000000000000
> > INFO:iMPACT:630 - '1': Expected IDCODE: 00000001001001001010000010010011
> >
> > I've found that this problem is discussed in the Xilinx web page:
> >
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=
> > 1&getPagePath=16490
> >
> > However, I don't use the encryption function for the bitstream. Why I
still
> > get the problem?
> > Even I install the service pack 3, the problem is still there.
> > Can anyone kindly tell me how to solve it?
> > Thanks in advance.
> >
> > tk
> >
> >
> > PS:  the following are the options used by BitGen:
> >
> > Summary of Bitgen Options:
> > +----------------------+----------------------+
> > | Option Name          | Current Setting      |
> > +----------------------+----------------------+
> > | Compress             | (Not Specified)*     |
> > +----------------------+----------------------+
> > | Readback             | (Not Specified)*     |
> > +----------------------+----------------------+
> > | CRC                  | Enable**             |
> > +----------------------+----------------------+
> > | DebugBitstream       | No**                 |
> > +----------------------+----------------------+
> > | ConfigRate           | 4**                  |
> > +----------------------+----------------------+
> > | StartupClk           | JtagClk              |
> > +----------------------+----------------------+
> > | DCMShutdown          | Disable**            |
> > +----------------------+----------------------+
> > | DisableBandgap       | No**                 |
> > +----------------------+----------------------+
> > | CclkPin              | Pullup**             |
> > +----------------------+----------------------+
> > | DonePin              | Pullup**             |
> > +----------------------+----------------------+
> > | HswapenPin           | Pullup*              |
> > +----------------------+----------------------+
> > | M0Pin                | Pullup**             |
> > +----------------------+----------------------+
> > | M1Pin                | Pullup**             |
> > +----------------------+----------------------+
> > | M2Pin                | Pullup**             |
> > +----------------------+----------------------+
> > | PowerdownPin         | Pullup**             |
> > +----------------------+----------------------+
> > | ProgPin              | Pullup**             |
> > +----------------------+----------------------+
> > | TckPin               | Pullup**             |
> > +----------------------+----------------------+
> > | TdiPin               | Pullup**             |
> > +----------------------+----------------------+
> > | TdoPin               | Pullnone             |
> > +----------------------+----------------------+
> > | TmsPin               | Pullup**             |
> > +----------------------+----------------------+
> > | UnusedPin            | Pulldown**           |
> > +----------------------+----------------------+
> > | GWE_cycle            | 6**                  |
> > +----------------------+----------------------+
> > | GTS_cycle            | 5**                  |
> > +----------------------+----------------------+
> > | LCK_cycle            | NoWait**             |
> > +----------------------+----------------------+
> > | Match_cycle          | NoWait               |
> > +----------------------+----------------------+
> > | DONE_cycle           | 4**                  |
> > +----------------------+----------------------+
> > | Persist              | No*                  |
> > +----------------------+----------------------+
> > | DriveDone            | No**                 |
> > +----------------------+----------------------+
> > | DonePipe             | No**                 |
> > +----------------------+----------------------+
> > | Security             | None**               |
> > +----------------------+----------------------+
> > | UserID               | 0xFFFFFFFF**         |
> > +----------------------+----------------------+
> > | ActivateGclk         | No*                  |
> > +----------------------+----------------------+
> > | ActiveReconfig       | No*                  |
> > +----------------------+----------------------+
> > | PartialMask0         | (Not Specified)*     |
> > +----------------------+----------------------+
> > | PartialMask1         | (Not Specified)*     |
> > +----------------------+----------------------+
> > | PartialMask2         | (Not Specified)*     |
> > +----------------------+----------------------+
> > | PartialGclk          | (Not Specified)*     |
> > +----------------------+----------------------+
> > | PartialLeft          | (Not Specified)*     |
> > +----------------------+----------------------+
> > | PartialRight         | (Not Specified)*     |
> > +----------------------+----------------------+
> > | Encrypt              | No**                 |
> > +----------------------+----------------------+
> > | Key0                 | pick*                |
> > +----------------------+----------------------+
> > | Key1                 | pick*                |
> > +----------------------+----------------------+
> > | Key2                 | pick*                |
> > +----------------------+----------------------+
> > | Key3                 | pick*                |
> > +----------------------+----------------------+
> > | Key4                 | pick*                |
> > +----------------------+----------------------+
> > | Key5                 | pick*                |
> > +----------------------+----------------------+
> > | Keyseq0              | M*                   |
> > +----------------------+----------------------+
> > | Keyseq1              | M*                   |
> > +----------------------+----------------------+
> > | Keyseq2              | M*                   |
> > +----------------------+----------------------+
> > | Keyseq3              | M*                   |
> > +----------------------+----------------------+
> > | Keyseq4              | M*                   |
> > +----------------------+----------------------+
> > | Keyseq5              | M*                   |
> > +----------------------+----------------------+
> > | KeyFile              | (Not Specified)*     |
> > +----------------------+----------------------+
> > | StartKey             | 0*                   |
> > +----------------------+----------------------+
> > | StartCBC             | pick*                |
> > +----------------------+----------------------+
> > | IEEE1532             | No*                  |
> > +----------------------+----------------------+
> > | Binary               | No**                 |
> > +----------------------+----------------------+
> >  *  Default setting.
> >  ** The specified setting matches the default setting.
> >
> >
>



Article: 57227
Subject: Re: Xilinx Webpack bugs bugs bugs
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Thu, 26 Jun 2003 06:06:14 GMT
Links: << >>  << T >>  << A >>
Hi - 

The this-tool-is-no-damn-good thread pops up every few weeks.  I don't
use the ECS schematic editor, so I can't comment on the its quality or
lack thereof.  And I certainly don't want to get embroiled in the
schematics-vs-HDL debate which, along with cockroaches, will be the
only thing to survive a nuclear holocaust.  But I will make a couple
of observations.

First, use tools that have lots of users.  Any tool developer will
spend more time fixing and maintaining popular tools than those used
only by a handful of people.  And, the merits of HDLs aside, is there
any doubt that even the least popular FPGA HDL synthesis tool has at
least ten times as many users as ECS?  I know, I know--this isn't
fair.  But that's the way it is.  Unless you're Mr. Cisco, of course.

Second, use only those tools that add real value.  There are some
Xilinx tools--the FPGA editor, PACE, the floorplanner--that have a
useful GUI .  In fact, these tools wouldn't make much sense without a
GUI.  But does Project Navigator really add that much value over and
above a decent batch file that invokes tools from the command line?
Maybe the uber-GUI that ties all the tools together makes sense for
some users, but to me it's just one more thing that can break or do
inexplicable things.  All I'm saying is, don't use a tool just because
it's there; the benefit should exceed the pain.

And I agree - the Linear Tech SPICE tool is very nice.  The fact that
it's free doesn't hurt, either.

Bob Perlman
Cambrian Design Works


Article: 57228
Subject: Xilinx ML300 JTAG Configuration Problem
From: "tk" <tokwok@hotmail.com>
Date: Thu, 26 Jun 2003 14:15:38 +0800
Links: << >>  << T >>  << A >>
Hi all,

I have problem in configuring the xc2vp7 on the ML300 board. The
problem is described in the previous thread "ERROR:iMPACT:583".

I doubt that I have omitted some settings on the ML300 board during
programming (or have done sth wrong in iMPACT). There is a button
called "FPGA PROG" on the ML300 board. I've searched through the
documentation but I couldn't find out what's it for.

Does anyone have the experience on using ML300 that can share with me ?

Thanks very much.

tk



Article: 57229
Subject: Everything need a reset?
From: "Jay" <yuhaiwen@hotmail.com>
Date: Thu, 26 Jun 2003 14:28:53 +0800
Links: << >>  << T >>  << A >>
always @ (posedge(clkin))
        clkout <= ~clkout;

above is a single clk_div module, but when I do simulation, I can't get it
work.
I know the reason. without a reset signal to give it a initial value of '0'
or '1', the clkout will keep the value 'x' during simulation.
but there's no 'x' in FPGA or CPLD, the clkout will get whatever a value
after power up, and it can get work without additional reset.

just a example, but in my design I really have some modules that haven't a
reset.
How can I simulate this modules? in testbench I tried to initiate the
clkout, but failed.

(ISE5.1 + ModelSim)





Article: 57230
Subject: Re: Xilinx Webpack bugs bugs bugs
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 26 Jun 2003 02:32:23 -0400
Links: << >>  << T >>  << A >>
Patrick MacGregor wrote:
> 
> Amen brother!
> 
> The "pay" tools are essentially the same, and work just as deplorably.  I
> have a copy of ISE 5.2, and it uses the same sorry excuse for a schematic
> editor.  I invented the "hexplitive", which was swearing in base 16, when
> working with X schematic tools.
> 
...snip...
> I also can't buy into the HDL argument.  The reason is simple.  If you were
> a software developer and you needed your code to be as small as possible and
> run as fast as possible, what language would you use?  Well, every software
> developer I've ever met answers the same -- native assembly language for the
> processor in question.  No compiled code will be more efficient because of
> the layers of abstraction that higher level languages impose.  The embedded
> developers I've worked with always got a good chuckle out of their C
> language counterparts sucking up 100's of kilobytes of memory compared to
> the few K that their assembly code needed.

But you ignore the fact that very few embedded engineers need their code
to be "as small as possible" or "fast as possible".  That is because the
hardware gives lots of head room for very few bucks.  Likewise FPGAs
generally are more than fast enough and large enough and cheap enough
(did *I* say that?) for 95% of the designs to be done in HDL.  

Again for the same reason that few designers do an entire project in
assembly, I won't be doing any more schematic designs.  The last one I
did was a PITA to draw the gates needed for FSM design or worse, address
decoding.  Data path is not bad in schematic, but the random logic is no
fun at all and it takes up so much space when you try to view a large
design.  I don't mean disk space, I mean viewing space.  I can view an
equivalent project in a text editor much more easily than a schematic
editor.  


> HDL is the same.  You abstract designs (so that non-designers can pretend to
> be designers I suppose) and pay a penalty by having circuit bloat.  If you
> want the smallest design possible, and want it to run as fast as possible,
> you need to use the design equivalent of assembly coding -- i.e. schematics.
> A picture is worth a thousand words, so you can make a picture or type a
> thousand words.  Which one will be easier for someone else to understand,
> hmm?

There are lots of reasons to use HDLs, but trying to enable uneducated
hardware designers (or worse, software designers) is not one of them.  I
feel that to properly use an HDL you need to know what you expect for
hardware and then describe that in the HDL.  But again, very few people
have to have the "smallest" or the "fastest" design.  Mostly they have
goals which include schedules.  

As to the picture and word analogy, I find the words to suit design
better.  It takes a large picture and a lot of time to create it, to
equal those thousand words. 


> I recently talked to an FAE for an FPGA vendor.  He said that fully 80% of
> the designs he has seen are done in schematics.  You can even read about
> graphical versions of HDL coming out.  Sounds like schematics to me.  Except
> that you add a layer of obfuscation in there that will make for a more
> bloated design.  Why bother?

I don't know where you got this, but this sounds like an exaggeration. 
I would say he had it backwards, but I bet the schematic usage is less
than 20%. 


> An ironic thing to notice is that if you open many of the X design examples
> included with the tools, you'll see that they are schematic based.
> 
> With a schematic it is sooooo simple to identify each and every flop and see
> what it is doing in a simulation.  Something isn't working in HDL?  Good
> luck.  Oh yeah, and with schematics, you never have to do all that modeling
> nonsense.  While most "designers" are modeling what their circuit is
> supposed to do, I've already got it done, simulated, verified on the bench,
> off my plate and onto the next thing.

If you don't feel the need to simulate, then you are clearly doing very
simple designs.  The simulation is to make sure you are solving the
problem rather than just knowing what you are creating.  These are two
different problems.  


> I was taught the power of schematics and their companion, the timing
> diagram, when I was a wee engineer pup.  My first boss would sit me down and
> go over the schematics with me, asking me to justify each and every
> component on the page.  If there wasn't a good reason for it, it was gone.
> Amongst the many invaluable lessons he taught me was that every component in
> the circuit should have a reason.  Try doing that with an HDL abstraction.
> Most "designers" haven't a clue how that hunk of code they wrote got
> implemented in actual gates.  Scott Adams would probably call them
> "Duhsigners".
> 
> <getting off soapbox now>
> 
> So, I'm with you 100%.  Schematics rule.  Xilinx has no reason whatsoever to
> support schematics, as the bloated designs that HDLs produce force folks
> into buying larger, faster speed grade parts that are naturally  more
> costly.  Works for them.
> 
> You can always download the free Altera tools and play with their stuff.
> Fully integrated schematic capture, compiler and simulator.  Very nice.  Not
> perfect or bug free, but then no tool is.  It is, however, VASTLY superior
> to the X garbage schematic tools.
> 
> When I need to design something in an X part, I do it first in the A tools
> and use their native simulater.  Then I re-enter it in X.  Doing the
> drawings twice is STILL faster than doing the design from scratch in X.  Try
> it.
> 
> I tend to always push my clients to use A parts simply because the tools are
> so superior.  Design times are radically reduced, and that saves them
> tangible money.  If they insist on X parts, I revert to the paragraph above.
> 
> Don't buy into the HDL propaganda.  Schematics will never do you wrong.

No, but they will take more time and make large jobs nearly impossible.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 57231
Subject: Handelc, Plzzz help
From: "P. Prasad" <pprasad@chandra.cse.iitb.ac.in>
Date: Thu, 26 Jun 2003 12:16:20 +0530
Links: << >>  << T >>  << A >>
hi,

  I am working on a HANDELC project on Xilinx FPGA(RC1000 board) and using Celoxica's DK1 environment. I have some doubts regarding HANDELC. I am new to HANDELC and FPGA.


The Problem
-----------

As the project is getting bigger and bigger, the compilation(synthesis into EDIF) time  is taking many hours. So the goal is to reduce the compilation time.

The approach which I tried to use was to break up the program into smaller parts, compile these into separate EDIFs and hook them into the main HANDELC program using interfaces(ports). So the parts of the program which have already been synthesized into EDIF do not take any time at all thus saving lot of time.

But I am doing some mistake in my code and I am clueless to what is wrong. Actually I feel that I need to synchronise the EDIF component with the main HANDELC program but don't know how ( maybe use interfaces properly???). I have given below the detailed description of the things I tried.


Here is the code for the main HANDELC program:(compiles to test.edf)
---------------------------------------------


#define PP1000_32BIT_RAMS
#define PP1000_DIVIDE4

#define PP1000_CLOCK	PP1000_MCLK

#include "C:\rc1000pp\fpga\virtex\pp1000.h"

set part = "V1000BG560-4";
set family = XilinxVirtex;

unsigned 8 value;

/* here interface to the component is defined */
interface test2
		(unsigned 8 ret_val)
	test2_instance
		(unsigned int 8 x = value);
void main (void)
{
	/****
	Interaction with the board is done .
	just reading some data from Memory banks which is written
	by a VC++ host program using RC1000 board API.
	Actually this data needs to be processed.
	To simplify the issue it's not given here.
	This is gauranteed to be correct, I tested it.
	****/

	value = 10; /* input to component EDIF */

	/* trying to use the EDIF component */
	while(test2_instance.ret_val == 0){delay;};
	value = test2_instance.ret_val;

	/****
	Interaction with board.
	just writing some processed data into memory bank.
	This part is gauranteed to be correct, I tested it. */
	****/
}

HANDELC code for the EDIF component (it compiles to test2.edf)
-----------------------------------

unsigned 8 value1;

interface port_in
		(unsigned int 8 x)
	comp_inp
		();

interface port_out
		()
	comp_outp
		(unsigned 8 ret_val = value1);


set clock = external; /* I am clueless here what clock to use */
void main(void)
{
	value1 = comp_inp.x * 10;
}


First I compile the above code to get test2.edf and then use the Xilinx place and route tool to merge both the edifs to get test.bit file.

But the above program does not work at all. Always I get value 0 when i read from the memory bank but the value is supposed to be 100. Also another suspicious thing is that the check for (ret_val==0) in the main HANDELC code surprisingly takes a long time (around 8 secs).

One more observation is that even if I explicitly write a value after the two statements as given below:

	/* trying to use the EDIF component */
	while(test2_instance.ret_val == 0){delay;};
	value = test2_instance.ret_val;

	value = 100; /* introduced now just to debug*/

	/****
	Interaction with board.
	just writing some processed data into memory bank.
	****/


still it gives 0. But if I remove the two statements trying to access the component, without removing the newly introduced statement,then the read value is 100 as required .


Plzzzzz help.

regards,

P.Prasad


Article: 57232
(removed)


Article: 57233
Subject: Re: Xilinx Webpack bugs bugs bugs
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 26 Jun 2003 08:58:15 +0100
Links: << >>  << T >>  << A >>
"Patrick MacGregor" <patrickmacgregor@comcast.net> writes:
<snip>
> I also can't buy into the HDL argument.  The reason is simple.  If you were
> a software developer and you needed your code to be as small as possible and
> run as fast as possible, what language would you use?  Well, every software
> developer I've ever met answers the same -- native assembly language for the
> processor in question.  No compiled code will be more efficient because of
> the layers of abstraction that higher level languages impose.  The embedded
> developers I've worked with always got a good chuckle out of their C
> language counterparts sucking up 100's of kilobytes of memory compared to
> the few K that their assembly code needed.
> 

The point as already been made that very few people write the whole
thing in assembly.

> HDL is the same.  You abstract designs (so that non-designers can pretend to
> be designers I suppose) and pay a penalty by having circuit bloat.  If you
> want the smallest design possible, and want it to run as fast as possible,
> you need to use the design equivalent of assembly coding -- i.e. schematics.
> A picture is worth a thousand words, so you can make a picture or type a
> thousand words.  Which one will be easier for someone else to understand,
> hmm?
> 

HDL doesn't force abstration - you can write gate-level HDL.  There
are illustrious people populating this group who frequently do the
"design equivalent of assembly coding" in HDL.

Come to think of it, last time I did a schematic I used the
"abstraction" of a counter block, which hides flops inside it.  Only
if you know how to make a counter do you know "where every flop is".
And that's the same in HDL - I know I've written code that will mean a
counter gets built, so I know what flops there are there.

<snip>

> 
> With a schematic it is sooooo simple to identify each and every flop and see
> what it is doing in a simulation.  Something isn't working in HDL?  Good
> luck.  Oh yeah, and with schematics, you never have to do all that modeling
> nonsense.  While most "designers" are modeling what their circuit is
> supposed to do, I've already got it done, simulated, verified on the bench,
> off my plate and onto the next thing.
> 

What do you do when your two BGA packages aren;t talking to each other
and you haven't got the chance (because of signal integrity concerns)
to put a probe point on the board?

I go back to my simulation, with its models and all that 'waste of
time'.

Another advantage of this approach is that I can write a testbench
that covers all my (many) testcases and reports a pass or fail at the
end.  That way I can modify any code I like and know I haven't
recreated any old bugs.  Not quite so easy when staring at
waveforms...

<snip>

Just some thoughts from the other side!

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 57234
Subject: Bitstream description for Virtex2 Pro
From: fmadlener@gmx.de (Felix Madlener)
Date: Thu, 26 Jun 2003 08:28:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi,
i'm currently looking at Xapp151 which describes the rough format of
the bitstream for Virtex, Virtex-E and Virtex-EM. However I have a
Virtex 2 Pro (V2P20). Is there any similiar document for that
architecture?

And if not, is there someone who has tested this and can give my some
tips about differences?

TIA
Felix
-- 
/"\ ASCII ribbon campaign against HTML mail and postings.
\ /
 X  "Ich will eigentlich keinen Streit - ich will nur Recht haben"
/ \ Thorsten Gunkel am 15.01.2000

Article: 57235
Subject: Re: ERROR:iMPACT:583
From: "tk" <tokwok@hotmail.com>
Date: Thu, 26 Jun 2003 16:43:53 +0800
Links: << >>  << T >>  << A >>
the problem is solved!

There are two options in iMPACT in bounday-scan chain:
1. Automatically connect to cable and identify Boundary-Scan chain
2. Enter a Boundary-Scan Chain

If I choose 2, only the xc2vp7 is chosen, which causes the error.
If I choose 1, there are 2 devices detected in the bounday-scan chain,
namely xccace and xc2vp7. The xc2vp7 can be successfully programmed in this
case by assigning the correct .bit file.

"tk" <tokwok@hotmail.com> gl news:bde17q$igm$1@www.csis.hku.hk...
> I'm quite sure that the physical cable connection is ok
>
> actually, the platform I use is ML300 and I try to program the xc2vp7 via
> the
> Parallel Cable IV. Does anyone have the experience on it ? Are there any
> settings on the ML300 board I should pay attention to ?
>
> Thanks in advance.
>
> tk
>
> "Neil Glenn Jacobson" <neil.jacobson@xilinx.com> wrote in message
> news:3EF9F98F.30402@xilinx.com...
> > iMPACT is telling you that you are getting all 0's back from the device
> > when it is expecting the IDCODE.  Assuming the device is currently
> > unprogrammed, I would first check your physical cable connections to the
> > device making certain that the device itself and the cable are both
> > properly powered
> >
> > This error does not appear to be related to the software
> >
> > tk wrote:
> > > Hi all,
> > >
> > > I get the following error when I try to program xc2vp7 device using
> iMPACT
> > > (ISE 5.1i):
> > >
> > > ERROR:iMPACT:583 - '1': The idcode read from the device does not match
> the
> > > idcode in the bsdl File.
> > > INFO:iMPACT:629 - '1':  Device IDCODE :
00000000000000000000000000000000
> > > INFO:iMPACT:630 - '1': Expected IDCODE:
00000001001001001010000010010011
> > >
> > > I've found that this problem is discussed in the Xilinx web page:
> > >
>
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=
> > > 1&getPagePath=16490
> > >
> > > However, I don't use the encryption function for the bitstream. Why I
> still
> > > get the problem?
> > > Even I install the service pack 3, the problem is still there.
> > > Can anyone kindly tell me how to solve it?
> > > Thanks in advance.
> > >
> > > tk
> > >
> > >
> > > PS:  the following are the options used by BitGen:
> > >
> > > Summary of Bitgen Options:
> > > +----------------------+----------------------+
> > > | Option Name          | Current Setting      |
> > > +----------------------+----------------------+
> > > | Compress             | (Not Specified)*     |
> > > +----------------------+----------------------+
> > > | Readback             | (Not Specified)*     |
> > > +----------------------+----------------------+
> > > | CRC                  | Enable**             |
> > > +----------------------+----------------------+
> > > | DebugBitstream       | No**                 |
> > > +----------------------+----------------------+
> > > | ConfigRate           | 4**                  |
> > > +----------------------+----------------------+
> > > | StartupClk           | JtagClk              |
> > > +----------------------+----------------------+
> > > | DCMShutdown          | Disable**            |
> > > +----------------------+----------------------+
> > > | DisableBandgap       | No**                 |
> > > +----------------------+----------------------+
> > > | CclkPin              | Pullup**             |
> > > +----------------------+----------------------+
> > > | DonePin              | Pullup**             |
> > > +----------------------+----------------------+
> > > | HswapenPin           | Pullup*              |
> > > +----------------------+----------------------+
> > > | M0Pin                | Pullup**             |
> > > +----------------------+----------------------+
> > > | M1Pin                | Pullup**             |
> > > +----------------------+----------------------+
> > > | M2Pin                | Pullup**             |
> > > +----------------------+----------------------+
> > > | PowerdownPin         | Pullup**             |
> > > +----------------------+----------------------+
> > > | ProgPin              | Pullup**             |
> > > +----------------------+----------------------+
> > > | TckPin               | Pullup**             |
> > > +----------------------+----------------------+
> > > | TdiPin               | Pullup**             |
> > > +----------------------+----------------------+
> > > | TdoPin               | Pullnone             |
> > > +----------------------+----------------------+
> > > | TmsPin               | Pullup**             |
> > > +----------------------+----------------------+
> > > | UnusedPin            | Pulldown**           |
> > > +----------------------+----------------------+
> > > | GWE_cycle            | 6**                  |
> > > +----------------------+----------------------+
> > > | GTS_cycle            | 5**                  |
> > > +----------------------+----------------------+
> > > | LCK_cycle            | NoWait**             |
> > > +----------------------+----------------------+
> > > | Match_cycle          | NoWait               |
> > > +----------------------+----------------------+
> > > | DONE_cycle           | 4**                  |
> > > +----------------------+----------------------+
> > > | Persist              | No*                  |
> > > +----------------------+----------------------+
> > > | DriveDone            | No**                 |
> > > +----------------------+----------------------+
> > > | DonePipe             | No**                 |
> > > +----------------------+----------------------+
> > > | Security             | None**               |
> > > +----------------------+----------------------+
> > > | UserID               | 0xFFFFFFFF**         |
> > > +----------------------+----------------------+
> > > | ActivateGclk         | No*                  |
> > > +----------------------+----------------------+
> > > | ActiveReconfig       | No*                  |
> > > +----------------------+----------------------+
> > > | PartialMask0         | (Not Specified)*     |
> > > +----------------------+----------------------+
> > > | PartialMask1         | (Not Specified)*     |
> > > +----------------------+----------------------+
> > > | PartialMask2         | (Not Specified)*     |
> > > +----------------------+----------------------+
> > > | PartialGclk          | (Not Specified)*     |
> > > +----------------------+----------------------+
> > > | PartialLeft          | (Not Specified)*     |
> > > +----------------------+----------------------+
> > > | PartialRight         | (Not Specified)*     |
> > > +----------------------+----------------------+
> > > | Encrypt              | No**                 |
> > > +----------------------+----------------------+
> > > | Key0                 | pick*                |
> > > +----------------------+----------------------+
> > > | Key1                 | pick*                |
> > > +----------------------+----------------------+
> > > | Key2                 | pick*                |
> > > +----------------------+----------------------+
> > > | Key3                 | pick*                |
> > > +----------------------+----------------------+
> > > | Key4                 | pick*                |
> > > +----------------------+----------------------+
> > > | Key5                 | pick*                |
> > > +----------------------+----------------------+
> > > | Keyseq0              | M*                   |
> > > +----------------------+----------------------+
> > > | Keyseq1              | M*                   |
> > > +----------------------+----------------------+
> > > | Keyseq2              | M*                   |
> > > +----------------------+----------------------+
> > > | Keyseq3              | M*                   |
> > > +----------------------+----------------------+
> > > | Keyseq4              | M*                   |
> > > +----------------------+----------------------+
> > > | Keyseq5              | M*                   |
> > > +----------------------+----------------------+
> > > | KeyFile              | (Not Specified)*     |
> > > +----------------------+----------------------+
> > > | StartKey             | 0*                   |
> > > +----------------------+----------------------+
> > > | StartCBC             | pick*                |
> > > +----------------------+----------------------+
> > > | IEEE1532             | No*                  |
> > > +----------------------+----------------------+
> > > | Binary               | No**                 |
> > > +----------------------+----------------------+
> > >  *  Default setting.
> > >  ** The specified setting matches the default setting.
> > >
> > >
> >
>
>



Article: 57236
Subject: Partial Reconfiguration of RC1000
From: panjuhwa_fpga@yahoo.com (PanJuHwa)
Date: 26 Jun 2003 02:08:36 -0700
Links: << >>  << T >>  << A >>
Hi,

  Has anyone executed partial reconfiguration of RC1000 using the
RC1000-PP host support library provided by Celoxica(previously
Embedded Solutions Ltd)? Would like what are the steps to achieve
this?

  Thanks.

Article: 57237
Subject: Re: How to Capture a VGA display EXTERNALLY
From: "kryten_droid" <kryten_droid@ntlworld.com>
Date: Thu, 26 Jun 2003 11:26:04 +0100
Links: << >>  << T >>  << A >>
> What if I were to modify the data out such that its similar to NTSC and
then
> pass it the encoder core.
>
> Instead of VGA, I could output 1 field at a time 30 Hz
> (still at 640x480).

That sounds plausible.



Article: 57238
Subject: Re: Everything need a reset?
From: Jochen <frensch@xsys.de>
Date: Thu, 26 Jun 2003 03:49:21 -0700
Links: << >>  << T >>  << A >>
Hi Jay, 
 i'm using vhdl, but should work in verilog, too: declaring 'clkout', use an initial value! 

signal clkout: std_logic := '0'; 

perhaps, you will have to ignore a synthesis-warning... 



Article: 57239
Subject: CoreGen/Ngdbuild help
From: santi@eee.strath.ac.uk (Santi)
Date: 26 Jun 2003 03:52:28 -0700
Links: << >>  << T >>  << A >>
Hi all!

I have a problem while trying to reuse a IP generated with the Coregen
Tool.

I used the CoreGen (ISE 5.1) to generate my IP (everything seems ok)
and after I have reused that IP in another design using Synplify Pro
(like a black box, every thing ok, till here) and while trying to
synthesize in ISE I've got the error:

Ngdbuild:604: logical block 'XXX' with type
'YYY' could not be resolved. A pin name misspelling can cause this, a
missing edif or ngc file, or the misspelling of a type name. Symbol
'YYY' is not supported in target 'virtex2'.

I have no idea of what's going on. The IP core seems correct and the
edf/ngo files for the IP are present in the propper direcotry at
$Xilinx/coregen/

Some has had the same problem before? Maybe a problem with the
spelling of the ports (upper/lower case)?

Thanks,

Santi

Article: 57240
Subject: Re: Eighty layers of metal!
From: Bernd Paysan <bernd.paysan@gmx.de>
Date: Thu, 26 Jun 2003 13:04:09 +0200
Links: << >>  << T >>  << A >>
Robert Myers wrote:
> Possible solutions: get away from Manhattan
> routing (25% savings in wire delay--yawn)

He even said this was "novel". Looking at the 25 years old die of the 8086, 
45 angle wiring wasn't novel back then - when layout was made by hand, and 
digitized afterwards. What's novel is chip place&route tools that can 
handle 45 angle wiring.

Repeater/buffer insertion: nothing new, and trivial to do automatically.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Article: 57241
Subject: Re: Xilinx Webpack bugs bugs bugs
From: mrand@my-deja.com (Marc Randolph)
Date: 26 Jun 2003 04:59:43 -0700
Links: << >>  << T >>  << A >>
"Patrick MacGregor" <patrickmacgregor@comcast.net> wrote in message news:<TYmcncAzX4PaxGejXTWJhw@comcast.com>...
[snip]
> HDL is the same.  You abstract designs (so that non-designers can pretend to
> be designers I suppose) and pay a penalty by having circuit bloat.  If you
> want the smallest design possible, and want it to run as fast as possible,
> you need to use the design equivalent of assembly coding -- i.e. schematics.
[snip]
> Don't buy into the HDL propaganda.  Schematics will never do you wrong.

I believe your assumptions and comparisons of HDL are incorrect.  HDL
is not a normal programming language, and as such, can't be compared
to something like C.  And it does not cause circuit bloat. 
Incorrectly coded HDL can, but that's not the fault of the HDL - just
like inefficient assembly code (yes, there is such a thing) is not the
fault of the assembler.

And I'm am certainly not anti-schematic - I've done two decent sized
designs recently in Renoir.  But the sole reason I do them in
schematic form is to help myself and any others get a graphical
picture of what is going on because they are somewhat complex designs.
 It has NOTHING to do with the coding or implementation efficiency -
because it is not more efficient - at best, it is on par.  And as Rick
pointed out, on large designs it is difficult to "see" what is going
on because when you zoom out, you can't see details, and when you zoom
in, you lose some of the big picture.

Lastly, FPGA's don't have many of the things you put in schematics. 
Do you use ONLY 4 input LUTs and D-FF's on your schematics?  If you
use much more than that, you are using a form of abstraction as well.

Have fun,

   Marc

Article: 57242
Subject: Re: Xilinx Webpack bugs bugs bugs
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Thu, 26 Jun 2003 14:32:49 +0200
Links: << >>  << T >>  << A >>
>
> I also can't buy into the HDL argument.  The reason is simple.  If you
were
> a software developer and you needed your code to be as small as possible
and
> run as fast as possible, what language would you use?  Well, every
software
> developer I've ever met answers the same -- native assembly language for
the
> processor in question.  No compiled code will be more efficient because of
> the layers of abstraction that higher level languages impose.  The
embedded
> developers I've worked with always got a good chuckle out of their C
> language counterparts sucking up 100's of kilobytes of memory compared to
> the few K that their assembly code needed.
>
> HDL is the same.  You abstract designs (so that non-designers can pretend
to
> be designers I suppose) and pay a penalty by having circuit bloat.  If you
> want the smallest design possible, and want it to run as fast as possible,
> you need to use the design equivalent of assembly coding -- i.e.
schematics.
> A picture is worth a thousand words, so you can make a picture or type a
> thousand words.  Which one will be easier for someone else to understand,
> hmm?
>

I am an embedded systems programmer, and do a little bit of PLD design.  I
can't comment on X's schematic software - I have never used it, and I never
will.  I am expecting to work on a Xilinx fpga design soon, and I will use
either VHDL or Verilog.
Everyone is entitled to their own opinions, I suppose, but your comments on
C and assembly programming just do not match reality.  There are plenty of
cases where assembly is the appropriate language - I program with small
micros, which are wholy unsuited to high-level language.  I also program in
C on micros that are more suited for C, and I am well-versed in the sort of
assembly code the C compilers generate.  The reality is that for small,
limited micros, assembly can be significantly faster and more compact - say
half the size and double the speed for a good assembly programmer as
compared to a good embedded C programmer (i.e., one that knows how to get
the best out of a small micro), and maybe the same again compared to a good
general C programmer.

For big micros, especially 32-bitters, a good C programmer and a good C
compiler will beat a good assembly programmer every time - bar a few,
specialised routines where it is worth highly optomising assembly code.  The
idea of a compiler producing 100 K of bloat for 1K of program is laughable
(or a very badly configured linker...).  Now, I know that theoretically an
assembly programmer could beat the compiler - after all, there is nothing
that the compiler can do that the assembler programmer cannot do.  But
writing optimal assembly for big micros is a long, hard job, and programmers
must balance writing optimal code with writing correct, maintainable,
flexible and readible code.  As a quick example, if the program requires a
divide by a constant, the C compiler may optimise this to multiplying by its
reciprical, and (assuming the micro does not have hardware multiplication),
it might produce a series of in-line shifts and adds.  If the assembler
programmer expects that this constant might change, he would write a general
divide routine - it is bigger and slower than the compiler-generated code,
but far more understandable and more flexible for the future.


FPGA design is the same.  Some things can be better expressed as schematics,
especially for small designs, and some designers will work better with
schematics than HDL depending on their background, experiance, and
interests.  But to suggest that schematics are always easier to understand,
or to design, or will always generate faster/smaller circuits, is just
silly.

And as for a picture being worth a thousand words, please draw me a picture
that gives the equivilent information to the sentence "I'm taking my family
on holiday to Finland in a couple of weeks, where we will be visiting
Mumminland, Helsinki zoo, and a number of other attractions".  I'm sure you
could draw such a picture, and it would look very nice, but it would take
far longer to draw and be much less accurate than the sentence.




Article: 57243
Subject: Re: Xilinx Webpack bugs bugs bugs
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Thu, 26 Jun 2003 12:41:27 GMT
Links: << >>  << T >>  << A >>
Marc Randolph wrote:

<Good stuff snipped>

> Lastly, FPGA's don't have many of the things you put in schematics.
> Do you use ONLY 4 input LUTs and D-FF's on your schematics?  If you
> use much more than that, you are using a form of abstraction as well.

A larger abstraction used in schematics is the "wire" connecting between
FF's and LUT's.  This "wire" is an abstraction for a significant number
of switch boxes, muxes and pips.  FPGAs are more interconnect logic than
user logic.


-- 
Phil Hays

Article: 57244
Subject: Low-power FPGA
From: "Arash Salarian" <arash dot salarian at epfl dot ch>
Date: Thu, 26 Jun 2003 15:05:37 +0200
Links: << >>  << T >>  << A >>
Hi,

What's your suggestion for a low-power, battery operated FPGA design? What
family do you suggest? I guess the design should need something like 20K~30K
gates (yeah, I know this does not all that correct but I've not syntesized
the design yet and can't give a good estimate on number of LEs or FFs...).
From what I've seen in data-sheets, besides the power consumption, one major
concern is the power-up and configuration current for SRAM based devices.
Also I'd like to have the minimum number of VCC voltages on the board and
other parts used in the design are 3.3v and can be safely run using a single
rechargable battery with no need for DC-DC converter circuit (it means that
they can work from 2.7v to 4.1v with no problem).

Best Regards
Arash



Article: 57245
Subject: Free PAL synth tools (ABEL, PALASM, VHDL, etc.)?
From: Paul Urbanus <urbpublic@hotmail.com>
Date: 26 Jun 2003 13:23:06 GMT
Links: << >>  << T >>  << A >>
I have a design that I did almost 15 years ago that fits in a 20L10 PAL. 
This was written in ABEL, a PALASM like language, that was created by 
Data IO (now Synario).

I need to port this design to a 22V10, because these parts are more 
readily available. This design is for a peripheral for one of the early 
1980s home computers. After I port the design, I'm going to release it 
into the public domain so enthusiasts of this machine can modify it if 
they want. To facilitate this, I'd like to make sure that whatever tool 
I use to synthesize the design can be had for free.

I'd prefer to use ABEL, because that would require the minimum amount of 
design changes. Does anyone know if there are any old versions of ABEL 
(by Data IO, now Synario) that have been released into the public 
domain? If not, can anyone recall what form of copy protection, if any, 
was used on the old DOS versions.

I know that Cypress has their Warp VHDL compiler for simple PALs, 
including the 22V10. But, it still costs about $100. Are any of the 
earlier versions available for free?

I guess I could always use PALASM. Anywone if the latest version of this 
tool supports the 22V10? And where can I find it?

Or, are there other options I'm not aware of.

TIA

Paul


______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
      <><><><><><><>   The Worlds Uncensored News Source   <><><><><><><><>
  

Article: 57246
Subject: Re: Low-power FPGA
From: "Willem Oosthuizen" <willy@asic.co.za>
Date: Thu, 26 Jun 2003 15:53:07 +0200
Links: << >>  << T >>  << A >>
I would suggest using ACTEL. They have both otp devices and flash devices.
These devices consume very little current 5mA standby.

"Arash Salarian" <arash dot salarian at epfl dot ch> wrote in message
news:3efaef99$1@epflnews.epfl.ch...
> Hi,
>
> What's your suggestion for a low-power, battery operated FPGA design? What
> family do you suggest? I guess the design should need something like
20K~30K
> gates (yeah, I know this does not all that correct but I've not syntesized
> the design yet and can't give a good estimate on number of LEs or FFs...).
> From what I've seen in data-sheets, besides the power consumption, one
major
> concern is the power-up and configuration current for SRAM based devices.
> Also I'd like to have the minimum number of VCC voltages on the board and
> other parts used in the design are 3.3v and can be safely run using a
single
> rechargable battery with no need for DC-DC converter circuit (it means
that
> they can work from 2.7v to 4.1v with no problem).
>
> Best Regards
> Arash
>
>



Article: 57247
Subject: Re: Xilinx Webpack bugs bugs bugs
From: "Patrick MacGregor" <patrickmacgregor@comcast.net>
Date: Thu, 26 Jun 2003 10:08:20 -0400
Links: << >>  << T >>  << A >>

"Thomas" <tom3@protectedfromreality.com> wrote in message
news:oprrcygwqomo2d8p@news3.news.adelphia.net...
> I read with interest your thoughts about hdl vs schematics and the
parallel
> with software
> I've developped software for 14 years and while at heart I agree with you,
> in my day to day practice I disagree. Assembler will always provide you a
> most optimized solution, but C/C++ is much faster to develop with and is
> more accessible; btw, that's assuming you have competent engineers writing
> assembler, otherwise it turns into a mess very quick. yes, you definetly
> lower the efficiency of the resource usage with a higher level language,
> but nowadays it is cheaper to get faster / bigger hardware than more
> engineers / time.
> the days where we used to build things right are over; now the key is how
> fast you can put something on the market; it's sad, but the tech industry
> is not what it used to be.
> I have never been too much in touch with the hardware industry, but lately
> it has changed and I realize that you guys have the exact same issues /
> concerns / problems / etc we have in software; kind of ironic, in a sad
> way.
>
> Thomas.

The assembly level guys I've worked with were every bit as fast as their C
counterparts when developing code.  If you do it a lot, you get good, fast
and efficient at it.  And as with HW design, you create a bag of tricks you
employ to speed the next jobs along, as well as developing a library of
previously designed pieces you can employ later.

There is just no reason why you can't design quickly and correctly at the
same time.  That is one key difference between a newbie and someone with a
lot of experience.  It is then incumbent on the experienced folks to pass
along knowledge to the newbies to speed their development into capable,
competent designers.  Nothing beats experience.




Article: 57248
Subject: Re: Xilinx Webpack bugs bugs bugs
From: "Patrick MacGregor" <patrickmacgregor@comcast.net>
Date: Thu, 26 Jun 2003 10:32:21 -0400
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3EFA9377.E87AB5E7@yahoo.com...
> Patrick MacGregor wrote:
> >
> > Amen brother!
> >
> > The "pay" tools are essentially the same, and work just as deplorably.
I
> > have a copy of ISE 5.2, and it uses the same sorry excuse for a
schematic
> > editor.  I invented the "hexplitive", which was swearing in base 16,
when
> > working with X schematic tools.
> >
> ...snip...
> > I also can't buy into the HDL argument.  The reason is simple.  If you
were
> > a software developer and you needed your code to be as small as possible
and
> > run as fast as possible, what language would you use?  Well, every
software
> > developer I've ever met answers the same -- native assembly language for
the
> > processor in question.  No compiled code will be more efficient because
of
> > the layers of abstraction that higher level languages impose.  The
embedded
> > developers I've worked with always got a good chuckle out of their C
> > language counterparts sucking up 100's of kilobytes of memory compared
to
> > the few K that their assembly code needed.
>
> But you ignore the fact that very few embedded engineers need their code
> to be "as small as possible" or "fast as possible".  That is because the
> hardware gives lots of head room for very few bucks.  Likewise FPGAs
> generally are more than fast enough and large enough and cheap enough
> (did *I* say that?) for 95% of the designs to be done in HDL.
>

In 20 years in this business (primarily telecom/datacom), I've never once
had a situation where bloat was allowed.  Bloat = added cost that doesn't go
away.  You burden every finished product with unecessary cost simply by poor
design practices.  A few dollars difference in parts doesn't mean much when
you build 10.  But when you built 100,000 it suddenly means a lot.  I've had
to sweat R's and C's many times, trying to remove as many as possible, and
then try to make the remaining ones use similar values as much as
possible -- all to try and minimize costs (cost of parts, cost of time for
the person ordering different parts, cost of warehousing -- it all counts if
you think about it).

Having recently done an OC48 framer design (in a couple of weeks), I could
have easily aimed at something like a 1C6 or 1C12 Cyclone part.  Instead I
aimed for a 1C3 part in the slowest speed grade.  Works just fine, using
about 1/3 of the LCs.  A 1C3 costs 1/2 of a 1C6 roughly, yet the 1C6 is not
"expensive".  Choosing to design efficiently added exactly zero time penalty
but yielded tremendous cost savings.

> Again for the same reason that few designers do an entire project in
> assembly, I won't be doing any more schematic designs.  The last one I
> did was a PITA to draw the gates needed for FSM design or worse, address
> decoding.  Data path is not bad in schematic, but the random logic is no
> fun at all and it takes up so much space when you try to view a large
> design.  I don't mean disk space, I mean viewing space.  I can view an
> equivalent project in a text editor much more easily than a schematic
> editor.
>
One startup I worked for had an embedded designer assigned to one or more
ATM interface cards.  These guys wrote in assembly only, and because of this
were able to keep up with ATM at OC-3 rates using a very slow, primitive
(i.e. inexpensive) micro.

The fact that random gate design being "no fun at all" and "taking up a lot
of space" suggests a few things to me.  First, there are some simple rules
for making a clean, legible schematic.  Too bad schools never teach them.
Also, I firmly believe that nearly anyone can make a functioning design
given enough time.  This doesn't make it a good design.  Some designs are
better than others, and one way to get to the "good design" stage is to get
your fingers into the gates and learn how to work with them efficiently.

I regularly test whether or not an HDL can create logic more efficiently
than me.  It can't.  Not once has it implemented any type of decoding
function better than I can.  It can match me in terms of resources utilized,
but it can't best me.  By staying in the gates, I always have an instant
grasp of how large a design is getting.  I stopped one major piece of that
OC48 design simply because it was getting too large.  I knew that because I
could see it on the page and in the floorplanner.  Seeing the size forced me
to think about other ways to implement the process.  The first way worked,
but so what?  Not good enough.  I needed to reduce the size to stay
comfortably in the smaller part.

>
> > HDL is the same.  You abstract designs (so that non-designers can
pretend to
> > be designers I suppose) and pay a penalty by having circuit bloat.  If
you
> > want the smallest design possible, and want it to run as fast as
possible,
> > you need to use the design equivalent of assembly coding -- i.e.
schematics.
> > A picture is worth a thousand words, so you can make a picture or type a
> > thousand words.  Which one will be easier for someone else to
understand,
> > hmm?
>
> There are lots of reasons to use HDLs, but trying to enable uneducated
> hardware designers (or worse, software designers) is not one of them.  I
> feel that to properly use an HDL you need to know what you expect for
> hardware and then describe that in the HDL.  But again, very few people
> have to have the "smallest" or the "fastest" design.  Mostly they have
> goals which include schedules.
>
The best HDL folks I know are ones who use it like it was a schematic.  So,
in my mind, why bother?  And again, I've never had the luxury of NOT needing
the smallest/fastest design.  It's how I push 4 OC48s through a $30 part,
saving a client millions on NOT needing to buy a bunch of expensive ASSPs
for every board.

Size does count, and I can proudly say that "mine is smaller than yours".
;-)

> As to the picture and word analogy, I find the words to suit design
> better.  It takes a large picture and a lot of time to create it, to
> equal those thousand words.
>
Some folks are visual and some folks prefer the written word.  I'm obviously
visual for circuits and have no problem using the written word, like now,
for example.

>
> > I recently talked to an FAE for an FPGA vendor.  He said that fully 80%
of
> > the designs he has seen are done in schematics.  You can even read about
> > graphical versions of HDL coming out.  Sounds like schematics to me.
Except
> > that you add a layer of obfuscation in there that will make for a more
> > bloated design.  Why bother?
>
> I don't know where you got this, but this sounds like an exaggeration.
> I would say he had it backwards, but I bet the schematic usage is less
> than 20%.
>
I got this right from the horse's mouth.  I didn't make it up.  It was his
observation of designs he's seeing.  Why would he lie?  He has no vested
interest in any method his clients use.  Simply the stats he sees.

> > An ironic thing to notice is that if you open many of the X design
examples
> > included with the tools, you'll see that they are schematic based.
> >
> > With a schematic it is sooooo simple to identify each and every flop and
see
> > what it is doing in a simulation.  Something isn't working in HDL?  Good
> > luck.  Oh yeah, and with schematics, you never have to do all that
modeling
> > nonsense.  While most "designers" are modeling what their circuit is
> > supposed to do, I've already got it done, simulated, verified on the
bench,
> > off my plate and onto the next thing.
>
> If you don't feel the need to simulate, then you are clearly doing very
> simple designs.  The simulation is to make sure you are solving the
> problem rather than just knowing what you are creating.  These are two
> different problems.
>
Guess you missed it when I said I simulated the designs, right before
testing them on the bench.  I never skip simulating.  Again though, I prefer
the graphical waveform version as I get to see a nice, pretty picture of
what is happening and when.  It is very simple to pull up any flop in the
design and see it relative to anything else.  Makes debugging go 10 times
faster.  And, once I'm happy with it, I can transfer the simulator results
back into the input file so that I can compare expected to generated results
should I make changes or add new stuff.  What could be simpler?

>
> > I was taught the power of schematics and their companion, the timing
> > diagram, when I was a wee engineer pup.  My first boss would sit me down
and
> > go over the schematics with me, asking me to justify each and every
> > component on the page.  If there wasn't a good reason for it, it was
gone.
> > Amongst the many invaluable lessons he taught me was that every
component in
> > the circuit should have a reason.  Try doing that with an HDL
abstraction.
> > Most "designers" haven't a clue how that hunk of code they wrote got
> > implemented in actual gates.  Scott Adams would probably call them
> > "Duhsigners".
> >
> > <getting off soapbox now>
> >
> > So, I'm with you 100%.  Schematics rule.  Xilinx has no reason
whatsoever to
> > support schematics, as the bloated designs that HDLs produce force folks
> > into buying larger, faster speed grade parts that are naturally  more
> > costly.  Works for them.
> >
> > You can always download the free Altera tools and play with their stuff.
> > Fully integrated schematic capture, compiler and simulator.  Very nice.
Not
> > perfect or bug free, but then no tool is.  It is, however, VASTLY
superior
> > to the X garbage schematic tools.
> >
> > When I need to design something in an X part, I do it first in the A
tools
> > and use their native simulater.  Then I re-enter it in X.  Doing the
> > drawings twice is STILL faster than doing the design from scratch in X.
Try
> > it.
> >
> > I tend to always push my clients to use A parts simply because the tools
are
> > so superior.  Design times are radically reduced, and that saves them
> > tangible money.  If they insist on X parts, I revert to the paragraph
above.
> >
> > Don't buy into the HDL propaganda.  Schematics will never do you wrong.
>
> No, but they will take more time and make large jobs nearly impossible.

For the duhsigner, perhaps.  Personally, I've never found any job too large
for schematics, whether doing ASICs or FPGAs.  And, you need schematics to
design PCBs, so the extra practice doesn't hurt.


>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX



Article: 57249
Subject: Re: CoreGen/Ngdbuild help
From: Stephane Guyetant <sguyetan.dislikes.spam@IRISA.fr>
Date: Thu, 26 Jun 2003 16:35:21 +0200
Links: << >>  << T >>  << A >>
I had this error while implementing RAMs with BlockRAMs:
the blockram is a componant instanciated within the coregen-generated 
component which in my case was wrong (dualport vs single port).
I would suggest:
* make sure your library is compiled before your design.
* check the PORT MAP of the components

VHDL is case unsensitive. IIRC Verilog is case sensitive.


Santi wrote:
> Hi all!
> 
> I have a problem while trying to reuse a IP generated with the Coregen
> Tool.
> 
> I used the CoreGen (ISE 5.1) to generate my IP (everything seems ok)
> and after I have reused that IP in another design using Synplify Pro
> (like a black box, every thing ok, till here) and while trying to
> synthesize in ISE I've got the error:
> 
> Ngdbuild:604: logical block 'XXX' with type
> 'YYY' could not be resolved. A pin name misspelling can cause this, a
> missing edif or ngc file, or the misspelling of a type name. Symbol
> 'YYY' is not supported in target 'virtex2'.
> 
> I have no idea of what's going on. The IP core seems correct and the
> edf/ngo files for the IP are present in the propper direcotry at
> $Xilinx/coregen/
> 
> Some has had the same problem before? Maybe a problem with the
> spelling of the ports (upper/lower case)?
> 
> Thanks,
> 
> Santi




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