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 64675

Article: 64675
(removed)


Article: 64676
Subject: Re: Dedicated CLK lines in CPLD
From: "tbx135" <tbx135@msn.com>
Date: Sun, 11 Jan 2004 18:31:43 GMT
Links: << >>  << T >>  << A >>
> But poster above claims it is a bad design practice.

Use product term clocks at your own risk. Every time you change the design
and re-fit, your skew and delay can be different. You will be using lots of
signal routing resources if the clock tree is large. All this will just get
worse as the design is enlarged.

Global clocking resources have guaranteed skew times and delays regardless
of how dense the design is packed.



Article: 64677
Subject: PCB for FG456: layers
From: "Jaromir Kolouch" <kolouch@cedo.cz>
Date: Sun, 11 Jan 2004 10:54:29 -0800
Links: << >>  << T >>  << A >>
I am beginning the design with Spartan-3 in the FG456 package.

Can anybody give an estimate how many PCB layers are necessary for this 
package with 6 perimeter I/O rows and GND, VCCINT, VCCO inside? Is it 
possible to design reliable board for it without buried vias? 

Any response will be appreciated.



Article: 64678
(removed)


Article: 64679
Subject: image file reading in vhdl
From: suneethatata@yahoo.com (suneetha)
Date: 11 Jan 2004 10:56:54 -0800
Links: << >>  << T >>  << A >>
I want to read an image file into vhdl....how it could be done...can u
please explain it in detail...

Article: 64680
Subject: Re: Spartan-3 LC Development Kit from Insight (Memec)
From: Ralph Malph <noone@yahoo.com>
Date: Sun, 11 Jan 2004 14:11:19 -0500
Links: << >>  << T >>  << A >>
Remis Norvilis wrote:
> 
> And then Ralph Malph wrote:
> 
> > remis norvilis wrote:
> >>
> >> I'm considering to get Spartan-3 LC Dev. Kit (DS-KIT-3SLC400) from
> >> Insight. Anybody used it? Comments would be appreciated.
> >>
> >> Remis
> >
> > I couldn't find anything on the Insight web site about this.  Where did
> > you see the info?
> 
> Check this site:
> http://legacy.memec.com/devkits/americas.shtml

I do find the USB2.0 interface interesting.  Otherwise this is not
anything special that I can see.  Is there any additional info
available?  How about a user guide?  I am always suspicious when the USB
2.0 term is used.  This does not always mean high speed.  

I would like to see more IO made available on a module like this.  If
they used a BGA package with a lot more IO, I could do some prototyping
with it.

Article: 64681
Subject: Re: Spartan3 prices again...
From: Ralph Malph <noone@yahoo.com>
Date: Sun, 11 Jan 2004 14:26:48 -0500
Links: << >>  << T >>  << A >>
Bob Perlman wrote:
> 
> On 30 Dec 2003 09:53:47 -0800, news@sulimma.de (Kolja Sulimma) wrote:
> 
> >> If you think there's even a chance that you're going to be designing
> >> in a certain component, get a formal price quote from the salesman,
> >> rep, or distributor.  And if you can't get a quote, maybe you can't
> >> get the part, either.
> >> > Bob Perlman
> >> Cambrian Design Works
> >
> >The issue was, that the formal quotes for pieces in 5k quantities
> >where a factor of 20 above the prices quoted by Xilinx for 250k
> >quantities.
> >And nobody in this group really believed that you get a 95% volume
> >discount.
> 
> If a formal quote for 5k pieces comes in at 20X a formal quote for
> 250k pieces, that's interesting information.  But if a formal quote
> for 5k pieces is 20X the 250k price stated in a press release, that's
> hardly surprising.
> 
> Which is it?
> 
> Any price you see in a press release should have a "j" after it.

"J" for joke?  

A friend told me that the 50,000 piece price on the slowest XC3S400 in
the FG456 package would be around $20.  The press releases are talking
about the "smallest" package and 250,000 quantities giving a price
around $5.  I don't know what the "smallest" package is, but I would
like to meet the guy who is getting the $5 price.  Seems to me the whole
point of the Spartan 3 chips is low price.  They are not faster, or
lower power or anything else other than cheap.  If they don't come in
below the competition, what good are they?  Heck, with three power
supplies and very touchy IO voltage specs, they seem to me like a PITA
to design in!

Article: 64682
Subject: Altera Cyclone data is incomplete or messy
From: Rene Tschaggelar <none@none.none>
Date: Sun, 11 Jan 2004 19:38:15 GMT
Links: << >>  << T >>  << A >>
Browsing the 'cyclone device handbook' I spent a great
length to find :
-the max current for each supply ( VCCIO & VCCINT )
-the expected clocking frequency at the input. I'm aware
  that 1MHz may not be sufficient to PLL it up to 400MHz
  or such.

to little avail. While I can live with 2 switchmode supplies
generating 1.5V and 3.3V at 2A each, and a generic 8pin
socket to swap oscillators for a prototype, the documentation
is somehow inclomplete.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 64683
Subject: Altera Cyclone Programming device programming
From: Rene Tschaggelar <none@none.none>
Date: Sun, 11 Jan 2004 19:41:36 GMT
Links: << >>  << T >>  << A >>
The Altera Cyclone Programming device EPCS1 are shown
to be programmed in the AS mode requiring an own connector.
Since the JTAG was never officially declared outdated,
I'd expect a way to program the cyclone plus the EPCS1 in JTAG
mode. I wasn't able to find it yet though.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 64684
Subject: Re: Altera Cyclone Serial Configuration devices.
From: Ben Popoola <b.popoola@ntlworld.com>
Date: Sun, 11 Jan 2004 19:45:01 +0000
Links: << >>  << T >>  << A >>
Rene Tschaggelar wrote:
> I started reading some documents about the configuration
> devices EPCS1 & EPCS4. They appear to be programmed with a
> new download cable, the Byteblaster2.
> The Byteblaster2 claims compatibility with the previous models,
> the Byteblaster and the ByteblasterMV. Unfortunately, there
> is no schematics included in the Byteblaster2 datasheet.
> Is the 74HC244 being changed to a 74LV244 this time ?
> 
> 
> Rene

A link to the  schemtaic for the ByteBlaster II was posted on this site 
a while back !!


Article: 64685
Subject: Re: Programming and debugging the Altera Cyclone family
From: Ben Popoola <b.popoola@ntlworld.com>
Date: Sun, 11 Jan 2004 19:48:23 +0000
Links: << >>  << T >>  << A >>
Rene Tschaggelar wrote:

> According to the Serial Configuation Devices() Datasheet
> (chapter 4 of configuration handbook volume 2),
> I understand that the Cyclones and their configuration devices
> are programmed in the so called AS  mode with the Byteblaster2.
> 
> Debugging is done with the usual JTAG connector, I assume.
> The Byteblaster2 also supports JTAG.
> 
> Meaning I have to swap the connector ?
> 
> Rene

No, you do not have to swap the connector as the ByteBlaster II supports 
multiple configuration modes.

The JTAG functionality is always available, but depending on how you set 
the MSEL(0,1) pins, you can programming the cyclone devices either in AS 
or PS modes.


Article: 64686
Subject: Re: image file reading in vhdl
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sun, 11 Jan 2004 12:08:46 -0800
Links: << >>  << T >>  << A >>
suneetha wrote:
> I want to read an image file into vhdl....how it could be done...can u
> please explain it in detail...

http://groups.google.com/groups?q=vhdl+binary+file+read

-- Mike Treseler


Article: 64687
Subject: Re: PCB for FG456: layers
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Sun, 11 Jan 2004 20:18:32 GMT
Links: << >>  << T >>  << A >>
I believe you need six layers minimum.  No need for buried vias as far I as
know.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"






"Jaromir Kolouch" <kolouch@cedo.cz> wrote in message
news:ee81d5e.-1@WebX.sUN8CHnE...
I am beginning the design with Spartan-3 in the FG456 package.
Can anybody give an estimate how many PCB layers are necessary for this
package with 6 perimeter I/O rows and GND, VCCINT, VCCO inside? Is it
possible to design reliable board for it without buried vias?
Any response will be appreciated.



Article: 64688
Subject: Re: Programming and debugging the Altera Cyclone family
From: Rene Tschaggelar <none@none.none>
Date: Sun, 11 Jan 2004 20:40:28 GMT
Links: << >>  << T >>  << A >>
Ben Popoola wrote:
> Rene Tschaggelar wrote:
> 
>> According to the Serial Configuation Devices() Datasheet
>> (chapter 4 of configuration handbook volume 2),
>> I understand that the Cyclones and their configuration devices
>> are programmed in the so called AS  mode with the Byteblaster2.
>>
>> Debugging is done with the usual JTAG connector, I assume.
>> The Byteblaster2 also supports JTAG.
>>
>> Meaning I have to swap the connector ?
>>
>> Rene
> 
> 
> No, you do not have to swap the connector as the ByteBlaster II supports 
> multiple configuration modes.
> 

I figured out that Byteblaster2 masters different modes. What I wasn't
able to figure out yet was how to use the JTAG mode on the AS mode pins.
Meaning (Fig3-7 configuration handbook / cyclone device handbook vol1)
the AS mode uses Data, DCLK, nCs/nCSO, ASDI/ASDO, nConfig, Conf_Done, nCE.
And JTAG uses TCK, TMS, TDI, TDO.

> The JTAG functionality is always available, but depending on how you set 
> the MSEL(0,1) pins, you can programming the cyclone devices either in AS 
> or PS modes.
> 
Preferably I'd program the EPCS1 & the Cyclone with JTAG, and use the same
cable and connector for debugging too.
That was possible with the ACEX family at least.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 64689
Subject: Re: Altera Cyclone Serial Configuration devices.
From: Rene Tschaggelar <none@none.none>
Date: Sun, 11 Jan 2004 20:54:26 GMT
Links: << >>  << T >>  << A >>
Ben Popoola wrote:
> Rene Tschaggelar wrote:
> 
>> I started reading some documents about the configuration
>> devices EPCS1 & EPCS4. They appear to be programmed with a
>> new download cable, the Byteblaster2.
>> The Byteblaster2 claims compatibility with the previous models,
>> the Byteblaster and the ByteblasterMV. Unfortunately, there
>> is no schematics included in the Byteblaster2 datasheet.
>> Is the 74HC244 being changed to a 74LV244 this time ?
>>
>>
>> Rene
> 
> 
> A link to the  schemtaic for the ByteBlaster II was posted on this site 
> a while back !!

Thanks.
I have all messages 3 month back and was to find it.
One paper claims to redo BBMV into BB2, but without 1.5V.
The other, ...
I'll have a look at them anyway.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 64690
Subject: Re: Programming and debugging the Altera Cyclone family
From: Ben Popoola <b.popoola@ntlworld.com>
Date: Sun, 11 Jan 2004 21:11:28 +0000
Links: << >>  << T >>  << A >>
Rene Tschaggelar wrote:

> Ben Popoola wrote:
> 
>> Rene Tschaggelar wrote:
>>
>>> According to the Serial Configuation Devices() Datasheet
>>> (chapter 4 of configuration handbook volume 2),
>>> I understand that the Cyclones and their configuration devices
>>> are programmed in the so called AS  mode with the Byteblaster2.
>>>
>>> Debugging is done with the usual JTAG connector, I assume.
>>> The Byteblaster2 also supports JTAG.
>>>
>>> Meaning I have to swap the connector ?
>>>
>>> Rene
>>
>>
>>
>> No, you do not have to swap the connector as the ByteBlaster II 
>> supports multiple configuration modes.
>>
> 
> I figured out that Byteblaster2 masters different modes. What I wasn't
> able to figure out yet was how to use the JTAG mode on the AS mode pins.
> Meaning (Fig3-7 configuration handbook / cyclone device handbook vol1)
> the AS mode uses Data, DCLK, nCs/nCSO, ASDI/ASDO, nConfig, Conf_Done, nCE.
> And JTAG uses TCK, TMS, TDI, TDO.
> 
>> The JTAG functionality is always available, but depending on how you 
>> set the MSEL(0,1) pins, you can programming the cyclone devices either 
>> in AS or PS modes.
>>
> Preferably I'd program the EPCS1 & the Cyclone with JTAG, and use the same
> cable and connector for debugging too.
> That was possible with the ACEX family at least.
> 
> Rene

Yes, I agree entirely.

With the Actel proAsic devices ( flash based FPGA) not only do you do 
everything through the JTAG interface, but you can also add your own 
logic to the JTAG chain.

Thus, doing things like in-system programming are a stroll in the park.


Article: 64691
Subject: Re: Programming and debugging the Altera Cyclone family
From: Rene Tschaggelar <none@none.none>
Date: Sun, 11 Jan 2004 21:50:00 GMT
Links: << >>  << T >>  << A >>
Ben Popoola wrote:
> Rene Tschaggelar wrote:
> 
>> Ben Popoola wrote:
>>
>>> Rene Tschaggelar wrote:
>>>
>>>> According to the Serial Configuation Devices() Datasheet
>>>> (chapter 4 of configuration handbook volume 2),
>>>> I understand that the Cyclones and their configuration devices
>>>> are programmed in the so called AS  mode with the Byteblaster2.
>>>>
>>>> Debugging is done with the usual JTAG connector, I assume.
>>>> The Byteblaster2 also supports JTAG.
>>>>
>>>> Meaning I have to swap the connector ?
>>>>
>>> No, you do not have to swap the connector as the ByteBlaster II 
>>> supports multiple configuration modes.
>>>
>>
>> I figured out that Byteblaster2 masters different modes. What I wasn't
>> able to figure out yet was how to use the JTAG mode on the AS mode pins.
>> Meaning (Fig3-7 configuration handbook / cyclone device handbook vol1)
>> the AS mode uses Data, DCLK, nCs/nCSO, ASDI/ASDO, nConfig, Conf_Done, 
>> nCE.
>> And JTAG uses TCK, TMS, TDI, TDO.
>>
>>> The JTAG functionality is always available, but depending on how you 
>>> set the MSEL(0,1) pins, you can programming the cyclone devices 
>>> either in AS or PS modes.
>>>
>> Preferably I'd program the EPCS1 & the Cyclone with JTAG, and use the 
>> same
>> cable and connector for debugging too.
>> That was possible with the ACEX family at least.
>>
> 
> Yes, I agree entirely.
> 
> With the Actel proAsic devices ( flash based FPGA) not only do you do 
> everything through the JTAG interface, but you can also add your own 
> logic to the JTAG chain.
> 
> Thus, doing things like in-system programming are a stroll in the park.
> 

Hmm, and what should I do with the Cyclone ? Have 2 connectors, one
for the AS, doing the EPCS1 and the Cyclone and the other for the JTAG
debugging ?

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 64692
Subject: Protecting Designs - any suggestions
From: "tbx135" <tbx135@msn.com>
Date: Sun, 11 Jan 2004 21:56:04 GMT
Links: << >>  << T >>  << A >>
I am contemplation writing special apps core designs in VHDL for licensing.
Does anyone know how cores are protected against theft these days? Does
particular device targeting affect the protection scheme (if any)?

Thanks



Article: 64693
Subject: Re: Programming and debugging the Altera Cyclone family
From: Ben Popoola <b.popoola@ntlworld.com>
Date: Sun, 11 Jan 2004 22:56:52 +0000
Links: << >>  << T >>  << A >>
Rene Tschaggelar wrote:

> Ben Popoola wrote:
> 
>> Rene Tschaggelar wrote:
>>
>>> Ben Popoola wrote:
>>>
>>>> Rene Tschaggelar wrote:
>>>>
>>>>> According to the Serial Configuation Devices() Datasheet
>>>>> (chapter 4 of configuration handbook volume 2),
>>>>> I understand that the Cyclones and their configuration devices
>>>>> are programmed in the so called AS  mode with the Byteblaster2.
>>>>>
>>>>> Debugging is done with the usual JTAG connector, I assume.
>>>>> The Byteblaster2 also supports JTAG.
>>>>>
>>>>> Meaning I have to swap the connector ?
>>>>>
>>>> No, you do not have to swap the connector as the ByteBlaster II 
>>>> supports multiple configuration modes.
>>>>
>>>
>>> I figured out that Byteblaster2 masters different modes. What I wasn't
>>> able to figure out yet was how to use the JTAG mode on the AS mode pins.
>>> Meaning (Fig3-7 configuration handbook / cyclone device handbook vol1)
>>> the AS mode uses Data, DCLK, nCs/nCSO, ASDI/ASDO, nConfig, Conf_Done, 
>>> nCE.
>>> And JTAG uses TCK, TMS, TDI, TDO.
>>>
>>>> The JTAG functionality is always available, but depending on how you 
>>>> set the MSEL(0,1) pins, you can programming the cyclone devices 
>>>> either in AS or PS modes.
>>>>
>>> Preferably I'd program the EPCS1 & the Cyclone with JTAG, and use the 
>>> same
>>> cable and connector for debugging too.
>>> That was possible with the ACEX family at least.
>>>
>>
>> Yes, I agree entirely.
>>
>> With the Actel proAsic devices ( flash based FPGA) not only do you do 
>> everything through the JTAG interface, but you can also add your own 
>> logic to the JTAG chain.
>>
>> Thus, doing things like in-system programming are a stroll in the park.
>>
> 
> Hmm, and what should I do with the Cyclone ? Have 2 connectors, one
> for the AS, doing the EPCS1 and the Cyclone and the other for the JTAG
> debugging ?
> 
> Rene

I think that you can also program the EPCS1 via the Cyclone chip itself 
but I do not know how off head.

This might work:

(1) Configure the FPGA through the JTAG port.
(2) If you have an I/O connection between your logic in the Cyclone and 
a PC, download your configuration bitstream into the EPCS1 via your 
logic in the Cyclone.
(3) Turn the power off then on. The Cyclone should boot from the EPCS1.



Article: 64694
Subject: Re: PCB for FG456: layers Please dont use the Xilinx gateway to post articles
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 11 Jan 2004 23:30:36 GMT
Links: << >>  << T >>  << A >>
On Sun, 11 Jan 2004 10:54:29 -0800, "Jaromir Kolouch" <kolouch@cedo.cz> wrote:
>I am beginning the design with Spartan-3 in the FG456 package. 
>Can anybody give an estimate how many PCB layers are necessary for this package
>with 6 perimeter I/O rows and GND, VCCINT, VCCO inside? Is it possible to design
>reliable board for it without buried vias?
>
>Any response will be appreciated.


You have posted an article to comp.arch.fpga via the Xilinx
gateway to this news group. Unfortunately, this gateway
mistakenly allows HTML posting, and even turns text
postings into HTML. For all news groups, including
comp.arch.fpga, the format is supposed to be text only.
I have advised Xilinx about this problem, which they have
said they will fix, but no schedule.

This concerns me for 2 reasons. First, many other users of
comp.arch.fpga either can't read your postings, or it is a
pain, and secondly, I maintain the archive of this news
group at www.fpga-faq.com and I have to spend several
hours each month cleaning up the mess that is caused by
HTML posts.

(11/08/2003 www.fpga-faq.com is currently off the air due
to a Denial of Service attack. I expect that it will be
enabled again early next month)

An alternative free system that will allow you to read and
post articles to comp.arch.fpga and that does not have this
problem is the gateway provided by Google, which also
maintains archives (for all news groups) in text form only.
(The archive for this news group at google should have the
same content as the one I maintain, but mine has nicer
indices and threading by author, topic, and date)

You can use google starting from the following page:

   http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.arch.fpga

There is a link in the top right corner for posting. You
may have to create an identity before posting, but that is
free too.

Thanks

Philip Freidin


===================
Philip Freidin
philip@fliptronics.com
Host for WWW.FPGA-FAQ.COM

Article: 64695
Subject: Re: Synthesis in VHDL vs. Verilog
From: Jim Lewis <Jim@SynthWorks.com>
Date: Sun, 11 Jan 2004 15:35:02 -0800
Links: << >>  << T >>  << A >>
Both VHDL and Verilog have a synthesis subset.
Some aspects of the synthesis subset are intuitive,
you can't synthesize access types.

Both have a separate standard that govern the
synthesis subset. For VHDL this is 1076.6, for
Verilog it is 1364.1.  If you want to see vendors
support portable coding styles, ask them to support
these standards.  You do need to ask because for
EDA vendors supporting a standard is an investment.
They expect to get something in return - like users
buying their tools.

The VHDL synthesis standard is quite a bit broader
than the Verilog standard, particularly with respect
to registers.  For example, VHDL supports dual
edged registers (separate clocks or rising and
falling edges).  Some of this is representative of VHDL
being more popular for FPGA design (and FPGA's supporting
devices like this).

See also my follow up to the guy who stated:
"Verilog is a very simple language so it's easier for
the tools guys to get it right."


If you are making a saftey critical design, you
would be better off using VHDL.  There are lots of
ways to hang yourself with Verilog (and none of them
give you anything useful at the end of the day).

To sum this up in another way,
"On a bad day coding VHDL, the compiler is going to
abuse you (hence this explains why some hate VHDL),
however, on a bad day coding Verilog, you can embed
bugs that make it essential that you have a great
testbench to find."


Cheers,
Jim Lewis
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Chris Carlen wrote:
> Greetings:
> 
> I am reading J Bhasker's "Verilog HDL Synthesis" along with "A Verilog 
> Primer" in order to learn not only Verilog, but how to make sure I can 
> model designs in a way that is synthesizable.
> 
> What I have just learned is that the synthesis system (such as if I am 
> using Xilinx ISE Webpack and it's associated synthesis tools) dictates 
> what style must be followed, because one system might be able to 
> synthesize model 'A' and not 'B', whereas another system might be able 
> to synthesize 'B' and not 'A', even though models 'A' and 'B' are 
> functionally equivalent.
> 
> Thus, this leads to the question of how to I learn about what modeling 
> style will be synthesizable for my particular tools?
> 
> The text won't be able to teach me this, since it is just dealing with 
> the problem in general.  Obviously this must be in the tooll 
> documentation, so I would ask:
> 
> Is there good modeling style info in Xilinx tools so that one can learn 
> how to make synthesizable models for Xilinx tools reliably?
> 
> Finally, how to VHDL and Verilog compare in terms of *inherent* 
> synthesizability of models, or does the same problem essentially exist 
> for both?
> 
> Thanks for input.
> 
> Good day!


Article: 64696
Subject: Re: Synthesis in VHDL vs. Verilog
From: Jim Lewis <Jim@SynthWorks.com>
Date: Sun, 11 Jan 2004 15:35:14 -0800
Links: << >>  << T >>  << A >>
> Verilog is a very simple language so it's easier for
> the tools guys to get it right. 

This is an incorrect assumption.

Verilog is a less consise language.  If you don't follow
some adhoc methodology for coding styles, you will not
get it right.  This fact has been proven time and time
again by Verilog experts who have given numerous
conference papers how they overcame yet another Verilog
issue.  And by the way, according to my sources (Cliff C.)
this is not a feature that is being fixed in SystemVerilog.

VHDL is a very consise language.  Code written and
simulated in one simulator will behave exactly the
same in another simulator.

So going back to simple.  Verilog is simple to start
producing code, however, if you fail to follow the
adhoc rules of Verilog coding, it is very easy to
get it wrong.  Note, this happens to Verilog experts.
If you want to get it right with Verilog, you would
be best to invest in a Lint tool.

In VHDL many lint tool features are built into the
language.  As a result, you need to learn these rules
from either a good book or from a good class.
If you fail to learn these rules, getting started
will be painful to get by the compiler.  However,
once you produce working code the likely hood of it
being correct is much higher.

For example, at DVCon last year, a company who codes
their IP in Verilog and translates to VHDL has imposed
the strong typing rules of VHDL onto their Verilog
designers (via a lint tool).  75% of the time a lint
violation resulted in a real bug.  It is certainly
better to find these issues at compile/lint time
rather than spending time simulating an incorrect
design.


 > Personnally I stick strictly to Verilog 95, I'm not even
> considering using any Verilog 2001 constructs in synthesizable code for
> another year. As for things like System C, that's targeted at testbenches
> at the moment, I do think that there are any synthesis tools that can
> handle it.
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Article: 64697
Subject: Re: Xilinx ECS - connecting a single net to multiple bus lines?
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 11 Jan 2004 23:43:52 -0000
Links: << >>  << T >>  << A >>
>What's the way to do this? It's common for me to run into situations where 
>I have a bus or bus pin, and I need to connect the same net to different 
>lines on the bus. Another common one is I have 2 busses, both of which have 
>a line that should connect to a single net. The documentation doesn't seem 
>to give any hints. Thanks for any input.

What does "connect the same net to different lines on the bus" mean?

Do you want a mux or tri-state driver, to read a status bit when a
particular register is selected?  Or do you want a solid connection
100% of the time?

If you want a hard connection, then physically, you are merging
several nets into one.  That seems a bit strange if two of them
are part of the same bus.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 64698
Subject: Re: Dedicated CLK lines in CPLD
From: "Karl Olsen" <karl.olsen@mail.dk>
Date: Mon, 12 Jan 2004 01:15:40 +0100
Links: << >>  << T >>  << A >>
tbx135 <tbx135@msn.com> wrote:

>> But poster above claims it is a bad design practice.
>
> Use product term clocks at your own risk. Every time you change the
> design and re-fit, your skew and delay can be different. You will be
> using lots of signal routing resources if the clock tree is large.
> All this will just get worse as the design is enlarged.
>
> Global clocking resources have guaranteed skew times and delays
> regardless of how dense the design is packed.

Using non-dedicated clock networks on FPGAs is certainly dangerous, and
Xilinx ISE issues a warning when you do.  But in CPLDs like XC9500s, routing
should be predicable as it is done through a regular routing matrix, unlike
FPGAs.  And ISE gives no warning when using product term clocks.  If they
weren't safe to use, it would be a major fault of the fitter not to warn
about them.  In my XC9500XL designs using many product term clocks, I
haven't seen any problems with them.

A global clock network, while saving a product term in each macrocell and
giving a faster Tco, isn't very flexible as it can only be driven from the
three physical GLK pins, and not from internally generated signals.  So in
many designs, product term clocks are very handy.  Since the fitter readily
uses them, it would be a pity if you had to look through the .rpt file for
flipflop equations where the clock wasn't commented by "// GCK".

But all this is circumstantial evidence.  Could someone from Xilinx please
comment on whether product term clocks in XC9500 are safe or unsafe?

Karl Olsen



Article: 64699
Subject: Re: Synthesis in VHDL vs. Verilog
From: "Robert Sefton" <rsefton@abc.net>
Date: Sun, 11 Jan 2004 18:43:55 -0800
Links: << >>  << T >>  << A >>
> VHDL is a very consise language.  Code written and
> simulated in one simulator will behave exactly the
> same in another simulator.
>

Jim -

Concise means succinct, i.e., the opposite of verbose. I've never heard
anyone make that claim about VHDL. Maybe you meant precise?

Do you have a link to that DVCon paper? I'd like to read it. If not, can
you briefly summarize some of the rules this company imposed?

Thanks,

Robert





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