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 127475

Article: 127475
Subject: Re: TechXclusives from Xilinx
From: MikeShepherd564@btinternet.com
Date: Thu, 27 Dec 2007 23:20:16 +0000
Links: << >>  << T >>  << A >>
>Please suggest to your web developers that they...put technical
>documentation...at permanent URLs...

>Someone...pointed out years ago that URLs for real documents...
>should be persistent.  There was a paper on it, but I can't
>find it now.  Unfortunately few web developers have taken
>this to heart.

The point has probably been made in various places, but one is:

   http://www.useit.com/alertbox/980614.html

Mike

Article: 127476
Subject: Re: TechXclusives from Xilinx
From: Peter Alfke <alfke@sbcglobal.net>
Date: Thu, 27 Dec 2007 15:54:26 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 27, 3:20=A0pm, MikeShepherd...@btinternet.com wrote:
> >Please suggest to your web developers that they...put technical
> >documentation...at permanent URLs...
> >Someone...pointed out years ago that URLs for real documents...
> >should be persistent. =A0There was a paper on it, but I can't
> >find it now. =A0Unfortunately few web developers have taken
> >this to heart.
>
> The point has probably been made in various places, but one is:
>
> =A0 =A0http://www.useit.com/alertbox/980614.html
>
> Mike

I understand, and I agree somewhat. But we also have to realize that
this is a fast-changing technology, and something that was cool and
interesting in 2002 is now often obsolete and perhaps even misleading.
That's why we want to overhaul the old TechXclusives, throw some away,
and bring the others up to snuff. We want to cater to working
engineers, not to archaeologists...
An overview of FPGAs that stops with Virtex-II is not meaningful
anymore, and neither are complex asynchronous FIFO explanations, when
you get ready-made designs in the more modern Virtex chips.
Sometimes we will annotate the old stories with warnings that there
are better ways of designing with the more modern parts.
The same considerations should be applied to application notes. Most
of them that are 5 years old are more amusing than enlightening.
Scary...
Peter Alfke

Article: 127477
Subject: Re: TechXclusives from Xilinx
From: Eric Smith <eric@brouhaha.com>
Date: Thu, 27 Dec 2007 19:00:34 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> The same considerations should be applied to application notes. Most
> of them that are 5 years old are more amusing than enlightening.

I've found very useful info that is still relevant but much more than
five years old.  For example, your asynchronous clock switching
circuit, and Rob Weinstein's "flancter".  This is exactly the sort of
stuff that tends to get lost when someone gets a wild hair to "clean
up the web site".  Avnet dropped the flancter app note from their site
even though Rob tried to push them to keep it.  I've just used several
flancters in a new design this week, but I had to beg on the newsgroup
a few weeks ago to get people to send me a copy of the actual ap note.
(Thanks to everyone that helped out!)

So what if 98% of old XL4000 ap notes aren't relevant?  It costs
almost nothing to keep them archived in a directory somewhere, and
the other 2% may contain useful design techniques that haven't been
rewritten for the Virtex 5.  These old app notes may help engineers
create new designs for paying customers.

Since some XL4000 series parts are still in production, there may even
be engineers that occasionally have to maintain the designs or migrate
them to newer families.  Suppose the HDL source for something has an
explanation like "see the example on page 12 of XAPP271828", but the
app note and associated files are gone.  I've been through that
several time with other semiconductor vendors.

I've always lamented how difficult it is to find data on old parts.
When data sheets started being supplied in PDF form in the late 1980s,
one of my friends said that the problem was solved and that the data
would be around forever.  I immediately disputed that point, and
predicted that electronic data would be even more emphemeral than
paper.  Twenty years of experience confirm that.

Sigh.

Article: 127478
Subject: Re: Xilinx XST questions
From: Uncle Noah <nkavv@skiathos.physics.auth.gr>
Date: Thu, 27 Dec 2007 23:42:43 -0800 (PST)
Links: << >>  << T >>  << A >>
> xst has a quite good log output during synthesis. It precisely describes what it
> synthesises at which line, and what gets eliminated for what reason. That may
> give a clue about the reasons. At least for me, xst was always right and I caused
> the problem...

i'm afraid i have synthesized the multi-port register file alone as
well as in a smaller context, and things there go well.

i'm pretty sure that problems arise due to it being deep in the
hierarchy.

Kind regards
Nikolaos Kavvadias


Article: 127479
Subject: Re: Xilinx XST questions
From: Uncle Noah <nkavv@skiathos.physics.auth.gr>
Date: Thu, 27 Dec 2007 23:49:32 -0800 (PST)
Links: << >>  << T >>  << A >>
> yes, i agree ... i had the same feeling and behavior on some of my
> inference designs ... usually i could fix it by rewriting some pieces
> of the code (and thus not fulfilling the template) to get it to
> synthesize the logic i wanted ... although i must say it has improved
> a lot, nowadays i only get it when i try to do something with
> RAMB's...
>
> kind regards,
>
> Tim

Hi,

what i didn't say is that the block RAMs are always matched properly
at high-level synthesis time. It is when going down to low-level
synthesis that ISE chooses to delete some of them.

Anyway, i now use instantiations as well in my multi-port register
file generator. Now, the number of block RAMs is OK (none is deleted
in low-level synthesis), still strangely some logic that is otherwise
accessible is still being deleted.

So, now it is probably the time that we are stepping onto my
problematic code ;). Probably that weren't visible yet although the
processor would run properly about 10 firmware applications in both
simulator and S3SK environment (S3SK without the big register file).

Still, i believe ISE has problems with elaborating code to an IR. I
had to rewrite (either by hand or automatically) 4 times my code in
order to see the correct number of BRAMs after low-level synthesis.
All 4 cases work in simulation (GHDL).

Kind regards
Nikolaos Kavvadias

Article: 127480
Subject: Re: Xilinx XST questions
From: Uncle Noah <nkavv@skiathos.physics.auth.gr>
Date: Thu, 27 Dec 2007 23:58:08 -0800 (PST)
Links: << >>  << T >>  << A >>
> > The behavior of the design (did two versions: one with the VHDL code
> > generated by an ANSI C 300-line program and one using generates using
> > certain preprocessing for enabling the proper output multiplexers) is
> > inferred properly by both XST 7.1 (patch 4) and 9.2 (unpatched) when i
> > try to synthesize it as a top-level module. So this works.
>
> Is your objective a hardware description
> for synthesis or or a netlist generator?

The generator produces either generic RT-level VHDL code (BRAMs are
inferrable) or VHDL code with block RAM instantations. I have a hand-
written version with generates, too.

> Maybe some of the dimensions line up cleanly
> with the block ram structures while others don't.

I'm sure that they actually do.

> Consider writing a clean hdl description using block ram
> templates and muxes and compare results with the present design.
> Some related examples:
http://home.comcast.net/~mike_treseler/sync_fifo.vhdhttp://home.comcast.net/~mike_treseler/stack.vhd

Nice examples, but i have written a really clean description.

> Consider a code template rather than a black box.
> This gives synthesis some flexibility.

This was my hope. I didn't want to mess with black-boxes , especially
for something that is deep in the hierarchy. From a mental point of
view (expanding and contracting the design port requirements not at
the top-level) has problems. It could be doable, only if i was fixing
all the affected entity declarations (the generic initial values for
the number of read and write ports) throughout the design. I actually
did this with Perl scripts, so there is no excuse for XST.

> The main advantage to clean synthesis code is that the
> synthesis and simulation models are the same thing.

I also believe this in principle.

> > I have posted some of the questions to the Xilinx forums, but no
> > answers yet. Are the answering people all situated in the States (and
> > are kind of sleeping at this moment)?
>
> No. Having a hot toddy at the holiday party ;)
>
>         -- Mike Treseler

AAhhh, we don't have holiday parties here. We used to staff ourselves
with tons of pork, beef, liver and brains on a  January day :)

Kind regards
Nikolaos Kavvadias

Article: 127481
Subject: Initialization of arrays
From: posedge52@yahoo.com
Date: Fri, 28 Dec 2007 02:24:17 -0800 (PST)
Links: << >>  << T >>  << A >>
How does one initialize 'nibbles' in verilog the same way as 'longreg'
is initialised .. ?

reg [1023:0]    longreg =
576'h555555555555555D00014AB7AE08002143658709800054;
reg [3:0]       nibbles[0:256];

(Enviroment is Xilinx/Linux ISE xst)

I would prefer a vendor neutral way.... but if it's not possible
tweaks are ok :)

Article: 127482
Subject: Re: Core Generators...
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 28 Dec 2007 11:49:50 +0000
Links: << >>  << T >>  << A >>
On Thu, 27 Dec 2007 10:37:49 -0800, Duane Clark <junkmail@junkmail.com>
wrote:

>Brian Drummond wrote:
>> On Wed, 26 Dec 2007 07:06:39 -0800 (PST), John Adair
>> <g1@enterpoint.co.uk> wrote:
>> 
>>> The big advantage of using the core generator is to get a logic
>>> function that is difficult to infer in a language like VHDL or
>>> difficult to attain the required performance. 
>> 
>> Or which is easy to infer in a language like VHDL, but for which the
>> synthesis tools don't support particularly well.
>> 
>> A recent case here was a 256-element lookup table, inferred as a
>> constant array initialised via a function call (which called other
>> functions to create the data, and others to manipulate it into fixed
>> point format, round it, etc) A bit convoluted but too fast to see in
>> Modelsim..
>
>For that kind of a task, I prefer to write C code that directly 
>generates a VHDL package file with a constant array. I find it a lot 
>easier to code and debug (and change), and the level of C knowledge 
>required is not very high.

I avoid C wherever possible, though unfortunately it isn't always
possible. If I had to do this again, I would also generate a package,
but using VHDL. 

As far as simulation was concerned, it worked beautifully; and changes
were undoubtedly easier than dropping into C to re-create the package;
and adding package output from VHDL would be easy. 

There are limits to escaping  from low-level hardware generation to
higher level behavioural design creation; but mostly they are not
inherent in the language, and they are slowly being pushed further back.
This was partly an experiment to find out how far they have been pushed;
not very far yet, unfortunately.

- Brian

Article: 127483
Subject: Re: Xilinx XST questions
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 28 Dec 2007 11:50:39 +0000
Links: << >>  << T >>  << A >>
On Thu, 27 Dec 2007 04:29:22 -0800 (PST), Uncle Noah
<nkavv@skiathos.physics.auth.gr> wrote:

>Hi Brian
>
>thanks for your answer. A question:
>
>> Instantiate the module in the top level design and add a "box type"
>> attribute set to "black_box" (for syntax see e.g.http://www.xilinx.com/support/answers/9838.htm
>> After synthesis, check the synthesis report; your module should appear
>> as a black box (or primitive component).
>
>Actually, the black-box module is deep in the hierarchy. The hierarchy
>is something like:
>
>level0: /top-level
>level1: /top-level/foo
>level2: /top-level/foo/bar
>
>bar is the black-box module.
>
>Does your answer apply for this case too?

Yes

- Brian

Article: 127484
Subject: Re: Xilinx XST questions
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 28 Dec 2007 11:51:54 +0000
Links: << >>  << T >>  << A >>
On Thu, 27 Dec 2007 04:33:23 -0800 (PST), Uncle Noah
<nkavv@skiathos.physics.auth.gr> wrote:

>Hi

>I mean is it possible to run final timing analysis (e.g. after par)
>for the entire design (with the black-box included as proper).
>
After PAR, the black box IS included as proper. 
Translate (NGDbuild) does that, as I explained earlier.

- Brian

Article: 127485
Subject: Re: Core Generators...
From: "KJ" <kkjennings@sbcglobal.net>
Date: Fri, 28 Dec 2007 15:41:16 GMT
Links: << >>  << T >>  << A >>

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
news:2sn9n3907b7fmtqglonpglgj8ljt41q2fo@4ax.com...
> On Thu, 27 Dec 2007 10:37:49 -0800, Duane Clark <junkmail@junkmail.com>
> wrote:
>
<snip
>>> A recent case here was a 256-element lookup table, inferred as a
>>> constant array initialised via a function call (which called other
>>> functions to create the data, and others to manipulate it into fixed
>>> point format, round it, etc) A bit convoluted but too fast to see in
>>> Modelsim..
>>
>>For that kind of a task, I prefer to write C code that directly
>>generates a VHDL package file with a constant array. I find it a lot
>>easier to code and debug (and change), and the level of C knowledge
>>required is not very high.
>
> I avoid C wherever possible, though unfortunately it isn't always
> possible. If I had to do this again, I would also generate a package,
> but using VHDL.
>
> As far as simulation was concerned, it worked beautifully; and changes
> were undoubtedly easier than dropping into C to re-create the package;
> and adding package output from VHDL would be easy.
>
> There are limits to escaping  from low-level hardware generation to
> higher level behavioural design creation; but mostly they are not
> inherent in the language, and they are slowly being pushed further back.
> This was partly an experiment to find out how far they have been pushed;
> not very far yet, unfortunately.
>
Keep in mind though that those limits are most likely vendor dependent. 
I've used functions that manipulate reals to initialize constant arrays to 
produce lookup tables without any problems with vendor A...using vendor X or 
Syn, I'm still generating service requests to fix other deficiencies in 
their tool that breeze right through with A.  Doesn't help you if you're 
commited to vendor X, but if you're not, it might.

KJ 



Article: 127486
Subject: Re: TechXclusives from Xilinx
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 28 Dec 2007 08:02:09 -0800 (PST)
Links: << >>  << T >>  << A >>
Eric, these are very good points, and we will consider them when we
refurbish TechXclusives.
It's nice to be part of a newsgroup where intelligent people ventilate
intelligent views.
Happy New Year !
Peter Alfke
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Dec 27, 7:00=A0pm, Eric Smith <e...@brouhaha.com> wrote:
> Peter Alfke wrote:
> > The same considerations should be applied to application notes. Most
> > of them that are 5 years old are more amusing than enlightening.
>
> I've found very useful info that is still relevant but much more than
> five years old. =A0For example, your asynchronous clock switching
> circuit, and Rob Weinstein's "flancter". =A0This is exactly the sort of
> stuff that tends to get lost when someone gets a wild hair to "clean
> up the web site". =A0Avnet dropped the flancter app note from their site
> even though Rob tried to push them to keep it. =A0I've just used several
> flancters in a new design this week, but I had to beg on the newsgroup
> a few weeks ago to get people to send me a copy of the actual ap note.
> (Thanks to everyone that helped out!)
>
> So what if 98% of old XL4000 ap notes aren't relevant? =A0It costs
> almost nothing to keep them archived in a directory somewhere, and
> the other 2% may contain useful design techniques that haven't been
> rewritten for the Virtex 5. =A0These old app notes may help engineers
> create new designs for paying customers.
>
> Since some XL4000 series parts are still in production, there may even
> be engineers that occasionally have to maintain the designs or migrate
> them to newer families. =A0Suppose the HDL source for something has an
> explanation like "see the example on page 12 of XAPP271828", but the
> app note and associated files are gone. =A0I've been through that
> several time with other semiconductor vendors.
>
> I've always lamented how difficult it is to find data on old parts.
> When data sheets started being supplied in PDF form in the late 1980s,
> one of my friends said that the problem was solved and that the data
> would be around forever. =A0I immediately disputed that point, and
> predicted that electronic data would be even more emphemeral than
> paper. =A0Twenty years of experience confirm that.
>
> Sigh.


Article: 127487
Subject: Re: Xilinx EDK 9.2 problems under Centos 5
From: root <root@root.root>
Date: Fri, 28 Dec 2007 17:15:42 GMT
Links: << >>  << T >>  << A >>
On Thu, 2007-12-27 at 13:36 -0800, Duane Clark wrote:
> root wrote:
> > I installed Centos (linux) 5.1, Xilinx Webpack 9.2i.04, and EDK 9.2.02.
> > 
> > However, when i launch 'xpsgui', I see a bunch of warning messages in my
> 
> Try running just 'xps', rather than 'xpsgui'.

Wow, don't I feel stupid.  That was *exactly* the problem -- thank you!


Article: 127488
Subject: Re: Initialization of arrays
From: root <root@root.root>
Date: Fri, 28 Dec 2007 17:17:21 GMT
Links: << >>  << T >>  << A >>
On Fri, 2007-12-28 at 02:24 -0800, posedge52@yahoo.com wrote:
> How does one initialize 'nibbles' in verilog the same way as 'longreg'
> is initialised .. ?
> 
> reg [1023:0]    longreg =
> 576'h555555555555555D00014AB7AE08002143658709800054;
> reg [3:0]       nibbles[0:256];
> 
> (Enviroment is Xilinx/Linux ISE xst)
> 
> I would prefer a vendor neutral way.... but if it's not possible
> tweaks are ok :)

Have you tried?

reg [3:0] nibbles[0:256];
initial begin 
  nibbles[0] = <your_val>;
  nibbles[1] = <your_val>;
   ...
end


Article: 127489
Subject: Re: TechXclusives from Xilinx
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 28 Dec 2007 17:35:22 GMT
Links: << >>  << T >>  << A >>
Eric Smith <eric@brouhaha.com> wrote:

>Peter Alfke wrote:
>> The same considerations should be applied to application notes. Most
>> of them that are 5 years old are more amusing than enlightening.
>
>I've found very useful info that is still relevant but much more than
>five years old.  For example, your asynchronous clock switching
>circuit, and Rob Weinstein's "flancter".  This is exactly the sort of
>stuff that tends to get lost when someone gets a wild hair to "clean
>up the web site".  Avnet dropped the flancter app note from their site
>even though Rob tried to push them to keep it.  I've just used several
>flancters in a new design this week, but I had to beg on the newsgroup
>a few weeks ago to get people to send me a copy of the actual ap note.
>(Thanks to everyone that helped out!)
>
>So what if 98% of old XL4000 ap notes aren't relevant?  It costs
>almost nothing to keep them archived in a directory somewhere, and
>the other 2% may contain useful design techniques that haven't been
>rewritten for the Virtex 5.  These old app notes may help engineers
>create new designs for paying customers.
>
>Since some XL4000 series parts are still in production, there may even
>be engineers that occasionally have to maintain the designs or migrate
>them to newer families.  Suppose the HDL source for something has an
>explanation like "see the example on page 12 of XAPP271828", but the
>app note and associated files are gone.  I've been through that
>several time with other semiconductor vendors.
>
>I've always lamented how difficult it is to find data on old parts.
>When data sheets started being supplied in PDF form in the late 1980s,
>one of my friends said that the problem was solved and that the data
>would be around forever.  I immediately disputed that point, and
>predicted that electronic data would be even more emphemeral than
>paper.  Twenty years of experience confirm that.

I fully second this. Especially Asian companies are keen on throwing
out old datasheets. Back in the old days design companies used to have
several cabinets filled with datasheet books. Nowadays they have hard
drives full of datasheets. Websites like www.alldatasheet.com are very
valuable; perhaps someone should start www.allappnotes.com.

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

Article: 127490
Subject: Re: TechXclusives from Xilinx
From: johnp <johnp3+nospam@probo.com>
Date: Fri, 28 Dec 2007 11:05:33 -0800 (PST)
Links: << >>  << T >>  << A >>


Peter -

Have you thought about opening the Tech Exclusives up to outside
writers?
For example, Antti had some nice examples of using SRL16's in
interesting
ways.

Just a thought...

John Providenza

Article: 127491
Subject: Re: TechXclusives from Xilinx
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 28 Dec 2007 11:36:34 -0800 (PST)
Links: << >>  << T >>  << A >>
Good idea. We would of course edit such contributions. I thought about
this when the Flancter was mentioned. We will give credit,
meticulously, and will try to avoid any copyright issues... (Too many
lawyers)
Peter

On Dec 28, 11:05=A0am, johnp <johnp3+nos...@probo.com> wrote:
> Peter -
>
> Have you thought about opening the Tech Exclusives up to outside
> writers?
> For example, Antti had some nice examples of using SRL16's in
> interesting
> ways.
>
> Just a thought...
>
> John Providenza


Article: 127492
Subject: Spartan 3E 3.3V configuration reverse current situation
From: kislo <kislo02@student.sdu.dk>
Date: Fri, 28 Dec 2007 13:37:40 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi, as explained in the note : http://focus.ti.com/lit/an/slva159a/slva159a.pdf
.. the use of 3.3V for configuration results in a reverse current
which needs to be sinked by the power supply ..  can the two resistors
R3 and R4 in Figure 1 at http://focus.ti.com/lit/ds/symlink/tps75003.pdf
be used to sink this reverse current, or are a additional resistor
required ?

Article: 127493
Subject: Re: Spartan 3E 3.3V configuration reverse current situation
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 28 Dec 2007 14:09:07 -0800 (PST)
Links: << >>  << T >>  << A >>
Any load on the 2.5 V supply will sink current, but you have to scale
these resistors to a much lower value to be meaningful. At 75 kilohm
and 2.5 V, they sink only about 30 microamps. You may need 100 times
more current.
Peter Alfke

On Dec 28, 1:37=A0pm, kislo <kisl...@student.sdu.dk> wrote:
> Hi, as explained in the note :http://focus.ti.com/lit/an/slva159a/slva159a=
.pdf
> .. the use of 3.3V for configuration results in a reverse current
> which needs to be sinked by the power supply .. =A0can the two resistors
> R3 and R4 in Figure 1 athttp://focus.ti.com/lit/ds/symlink/tps75003.pdf
> be used to sink this reverse current, or are a additional resistor
> required ?


Article: 127494
Subject: Re: Initialization of arrays
From: posedge52@yahoo.com
Date: Fri, 28 Dec 2007 20:39:23 -0800 (PST)
Links: << >>  << T >>  << A >>
On 28 Dec, 18:17, root <r...@root.root> wrote:
> On Fri, 2007-12-28 at 02:24 -0800, posedg...@yahoo.com wrote:
> > How does one initialize 'nibbles' in verilog the same way as 'longreg'
> > is initialised .. ?
>
> > reg [1023:0]    longreg =
> > 576'h555555555555555D00014AB7AE08002143658709800054;
> > reg [3:0]       nibbles[0:256];
>
> > (Enviroment is Xilinx/Linux ISE xst)
>
> > I would prefer a vendor neutral way.... but if it's not possible
> > tweaks are ok :)
>
> Have you tried?
>
> reg [3:0] nibbles[0:256];
> initial begin
>   nibbles[0] = <your_val>;
>   nibbles[1] = <your_val>;
>    ...
> end

I have seen that in some other post. The catch is that it will require
reformatting of input data and becomes messy with frequent copy &
paste from binary->text generator into source code.
So I look for something where I can simply paste a hexstring right
into code as a initialisation string. It doesn't make sense that it's
alright for 1 bit wide arrays. But not for an 'n' wide array.

Article: 127495
Subject: Architectural level CMP simulators
From: Koustav <koustav79@gmail.com>
Date: Fri, 28 Dec 2007 21:12:07 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello everybody,

Does anybody have any idea of a multiprocessor simulator. I have
worked with uniprocessor architecture simulators based on
simplescalar. Please suggest some CMP simulators which are more or
less easy to build in Solaris/Linux machines. I would prefer using a
CMP simulator based on extension of simplescalar but I am open to try
my hands on anything new as well. Thanks in advance.

Koustav

Article: 127496
Subject: Re: Linux (not uClinux) on Microblaze 7.0 w/MMU?
From: rsl <rsl@rsl.com>
Date: Sat, 29 Dec 2007 06:29:41 GMT
Links: << >>  << T >>  << A >>
On Sun, 2007-11-04 at 22:15 -0800, Eric Smith wrote:
> Now that Xilinx has released Microblaze 7.0 with an optional MMU (in
> EDK 9.2), has anyone started working on a Linux port?
> 
> There's already a uClinux port to Microblaze with no MMU, but for
> some applications it would be nice to run "normal" Linux.

Lynuxworks already claims to have a (MMU) linux-port to Microblaze.
http://www.lynuxworks.com/embedded-linux/embedded-linux.php

Appnote ug258 is a precompiled demo of Bluecat Linux (Microblaze 
edition), for the Spartan3E Embedded Processing Kit (SP3E1600E.)
I tried it out, but since I couldn't really build/compile/test
my own applications on the embedded platform, it wasn't all
that useful.  (Basically, from a user perspective, looking
through the RS232 port and ethernet-jack, it looks just like
the prelodaed-uclinux demo.)


Article: 127497
Subject: Re: Initialization of arrays
From: rsl <rsl@rsl.com>
Date: Sat, 29 Dec 2007 06:40:22 GMT
Links: << >>  << T >>  << A >>
On Fri, 2007-12-28 at 20:39 -0800, posedge52@yahoo.com wrote:
> On 28 Dec, 18:17, root <r...@root.root> wrote:
> > Have you tried?
> >
> > reg [3:0] nibbles[0:256];
> > initial begin
> >   nibbles[0] = <your_val>;
> >   nibbles[1] = <your_val>;
> >    ...
> > end
> 
> I have seen that in some other post. The catch is that it will require
> reformatting of input data and becomes messy with frequent copy &
> paste from binary->text generator into source code.
> So I look for something where I can simply paste a hexstring right
> into code as a initialisation string. It doesn't make sense that it's
> alright for 1 bit wide arrays. But not for an 'n' wide array.

That's a limitation/idiosyncracy of Verilog.  What you call a "1-bit
wide array" isn't really an array at all -- it's a sized-vector.
In Verilog, 2-D arrays are 'unpacked' arrays, what have all sorts
of painful baggage (as you've found out.)

Verilog-2001 allows multi-dimensional packed-arrays, but they won't
help you out here.  

  reg [3:0] useless_packed_array [0:39][0:15]; // Verilog-2001
  integer i [3:0];

Systemverilog adds multi-dimensional UNpacked-arrays, which VHDL has
already supported since the dawn of time.  Of course, Xilinx XST will
need to catch up and start supporting Systemverilog.  (Altera Quartus
7.2 is already there!)

  logic [7:0][3:0] unpacked_array; // Systemverilog
  logic [7:0][3:0] unpacked_array2; // Systemverilog
  initial unpacked_array = { 8'd1, 8'd2, 8'd3, 8'd4 };
  initial unpacked_array2 = { default: '0 }; // all 0 
  integer [3:0] i;

^^^Ok I didn't check that in Modelsim -- someone will correct me if
   that's wrong!


Article: 127498
Subject: what is the difference between system side XAUI and line side XAUI?
From: "cationebox@gmail.com" <cationebox@gmail.com>
Date: Fri, 28 Dec 2007 23:11:31 -0800 (PST)
Links: << >>  << T >>  << A >>
would someone like to give me some  explanation about the difference
when XAUI work as line side interface or in system interface?
i am much puzziled about this concept.
thanks a lot

Article: 127499
Subject: JTAG chain detects Xilinx FPGA XCV150 instead of XC2S150...
From: Mir <irfanfaisalmir@gmail.com>
Date: Sat, 29 Dec 2007 01:42:34 -0800 (PST)
Links: << >>  << T >>  << A >>

Hi members,

I developed a Spartan-II (xc2s150-5pq208) based card. I also installed
Xilinx Flash (xcf01s) there. Unfortunately when I detect these chips
through JTAG, I found Xilinx Virtex (XCV150) device instead of Spartan-
II (XC2S150). Rest of all is fine..

I have already done the following..

1. Supplies are proper.. VCCO is 3.27V and VCCINT is 2.5V
2. Decoupling capacitors are there.. 0.1uF, 0.01uF (with most of power
pins) and 47uF (with most of IO banks)

Please anyone guide me... where is the mistake..?

I am so grateful to you.

Regards,
Mir



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