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 65200

Article: 65200
(removed)


Article: 65201
(removed)


Article: 65202
Subject: Re: BIST FPGA testing - Applying a test vector
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Thu, 22 Jan 2004 06:57:57 GMT
Links: << >>  << T >>  << A >>

Besides reiterating that our devices are tested thoroughly through our own
internal test programs, I should point out that it takes a large team of
engineers working for ~1 year before a chip is released to come up with the
suite of tests we throw at our chips to make sure that they function.  I
believe this includes tests of all varieties that you mention.

Even if you had the resources to develop a good suite of tests to achieve
99+% coverage of the parts of our chip your design uses, there are a huge
number of configurations required to achieve this coverage.  We employ
special test pins and test modes to improve the throughput and reduce the
data requirements for these configurations, but it still would take a hefty
amount of ROM to store the configs.

My guess would be that it would be cheaper to build redundant hardware (for
example, use triple modular redundancy) for your design than it would be to
develop and deploy a self-testing capability.  The chances that you've got a
fault that we didn't detect that isn't covered by your TMR circuitry would
be very very small.

Not that I'd have a problem with you finding a way to re-test EasyPath parts
yourself ;-)

Regards,

Paul Leventis
Altera Corp.



Article: 65203
Subject: Re: changing values in a fifo
From: "Blake Henry" <bhenry@bitwisesys.com>
Date: Thu, 22 Jan 2004 07:03:00 GMT
Links: << >>  << T >>  << A >>
Patrick,

The solution I proposed would address changes to all occurances in the FIFO.
See, the FIFO only stores the address of an entry in the CAM/RAM.  If the
value changes, the address remains the same, just the value in the CAM/RAM
gets changed.  Unfortunately, Altera's CAM Megafunctions don't allow direct
reading of the CAM entries by address thus necessitating the RAM.  The CAM
is simply used to determine whether a value has been submitted before or
not.  The RAM stores the same value as the CAM except you can read it out by
indexing into the RAM using the FIFO output.

Blake

"Patrick Klacka" <pklacka@trexenterprises.com> wrote in message
news:501364cc437d0c00562c49ae102caf01@news.teranews.com...
> Thank you everyone for your suggestions thus far. It's clear that more
> details are needed in order to better explore this problem. Please see
> http://www.trexenterprises.com/~pklacka/fifo.html for implementations in C
> code.
>
> It seems that all the solutions favor one change to a particular value,
but
> do not consider the case of the changed value being changed. For example,
> the value of 5 is changed to 6. Now a 5 is retrieved from the fifo. We
know
> through the Blake's CAM implementation and Jim's SyncRAM implementation
that
> the value of 5 will be transformed to a 6. Now the 6 is changed to a 7.
When
> we retrieve a 6 from the fifo, we get a 7 as intented. But should a 5 come
> off the fifo, we still get a 6, unless some sort of recursion is used. The
> recursion is what I am attempting to avoid. If all the 5's in the fifo
could
> be changed to 6's before the 6's get changed to 7's, then I have a working
> solution.
>
> Here is another idea that may be impossible to implement, but it might
shed
> some more light on what I am trying to achieve. Consider a full fifo that
> expects a value to be inserted every time you remove a value. So there is
a
> constant flow from one side to the other. (I think this was correctly
> likened to a vector shift-register) Could there be another fifo of the
exact
> same length that flowed in the opposite direction which contains the
compare
> and the change values. Each time a new value is inserted/removed from the
> primary fifo, the secondary fifo compares register values at the same
> location in the primary fifo, makes the appropriate change if necessary,
> then shifts itself with a new value. Using this idea, all of the 5's will
be
> changed to 6's before the 6's get changed to 7's, but I think it uses the
> same amount of resources as my original solution.
>
>



Article: 65204
Subject: Re: OT: liability insurance
From: "Blake Henry" <bhenry@bitwisesys.com>
Date: Thu, 22 Jan 2004 07:05:17 GMT
Links: << >>  << T >>  << A >>
Hello Ray,

Nice seeing your post.  Tell me, 1) what's involved in getting the P.E.
moniker and 2) do you carry product liability?

Blake

"Ray Andraka" <ray@andraka.com> wrote in message
news:400ECC6F.CF29C15D@andraka.com...
> $500/yr sounds like Commercial General Liability, which basically protects
> you if a customer hurts himself on your premises.  It doesn't generally
> provide any coverage for your product, in other words O&E.  My O&E runs
> about $6000/year, and is through a different insurer than my CGL.  There
are
> relatively few carriers that offer O&E, and you'll likely be locked out of
> it for certain products like medical instruments and nuclear controls.
>
> Robert Sefton wrote:
>
> > I'm a consultant/contractor. A new customer is requiring me to carry
> > commercial general liability coverage, including contractual liability
> > (errors and omissions). I carried a $1M policy from Hartford for several
> > years, but let it lapse in '02 after customers quit insisting on it. I
> > paid $500/yr back then. Any recommendations, and what should I expect to
> > pay? I'm in California.
> >
> > Thanks,
> >
> > Robert
> > (real email: rsefton@nextstate.com)
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 65205
Subject: Re: Non deterministic routing in Quartus 3.0 ?
From: giachella.g@laben.it (g. giachella)
Date: 21 Jan 2004 23:20:39 -0800
Links: << >>  << T >>  << A >>
vbetz@altera.com (Vaughn Betz) wrote in message news:<48761f7f.0401202037.79907801@posting.google.com>...
> Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<400D7312.1090304@flukenetworks.com>...
> > g. giachella wrote:
> > > I have launched the place & route of the same project on two different
> > > machines, a PC 2.6 GHz (WIN 2000) and a COMPAQ XEON 700 MHz
> > > Workstation (WIN NT 4). Same project means same .vhd, .edf, .csf,
> > > .psf, .ssf, .esf, .quartus files.
> > > The QUARTUS release is the same (same build, same SP).
> > > I obtained two different placements and two different compile times
> > > (PC = 1h 40 min, Workstation = 5h 22 min): the file ..fit.rpt
> > > evidences that the options "Use Local Routing Input" and "Use Local
> > > Routing Output" were set differently between them during the
> > > compilation.
> > > As the project are the same and the seed is also the same, I would
> > > expect identical place and route.
> > > 
> > > Any comment ? Am I missing somenthing ?
> > 
> > Your win2k box is faster than your nt box.
> > 
> > Lets assume that place & route is mostly compute bound.
> > In that case, if I didn't know the answer, I would
> > estimate the NT test time as:
> > 
> > (100 min) (2.6/.7) = 371 min = 6 hours
> > 
> > 
> > So you are doing better than I would expect.
> > 
> > 
> >      -- Mike Treseler
> 
> 
> The different compile time is just CPU speed differences, as Mike
> explained.  For the different placement and routing, I can only think
> of two things:
> 
> 1. You changed some option without realizing it between the two
> compiles.  Are "Use Local Routing Input" and "Use Local Routing
> Output" options you set for the compiler, and you're saying they have
> different values in the two fit.rpt files?  If so, that indicates you
> have unintentionally changed a setting between the two compiles, which
> would explain the different place and route.
> 
> 2. We have occasionally gotten different fits on different versions of
> Windows due to things like qsort breaking ties differently in
> different windows versions.  A slight difference at one point in the
> compile leads to a different fit on the two platforms.  Both are valid
> fits; they are just different.  As we find these cases, we get rid of
> them by doing things like writing our own qsort that breaks ties in a
> deterministic way.
> 
> So it's rare, but we do find these cases.
> 
> Regards,
> 
> Vaughn
> Altera

Thank you for your interest.
I have launched a new compilation on a pc only and, again, the result
is different from the previous launched on the same pc. I don't
understand why ...

Article: 65206
Subject: Re: OT: liability insurance
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 22 Jan 2004 07:28:06 GMT
Links: << >>  << T >>  << A >>
"Blake Henry" wrote:

> what's involved in getting the P.E. moniker

In the interest of accuracy (not criticism), "P.E." is not a moniker, which
means "nickname".

"PE" stands for "Professional Engineer".  A Google search using that phrase
reveals a world of information on the subject.


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

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




Article: 65207
Subject: Re: BIST FPGA testing - Applying a test vector
From: usenet_10@stanka-web.de (Thomas Stanka)
Date: 22 Jan 2004 00:28:28 -0800
Links: << >>  << T >>  << A >>
Hello,

Peter Alfke <peter@xilinx.com> wrote:
> Thomas Stanka wrote:
> > Anyway, you can't do tests before selling a fpga, that replaces Bist
> > for dynamic faults in the way I understood dynamic faults. Dynamic
> > faults will occure sometime during lifetime of the fpga due to
> > material aging or (especially in SRam based Fpgas) due to single event
> > effects.
[..]
> Single-event upsets are soft failures, mostly caused by various
> radiation types. They can only be described in statistical terms, and
> they disappear once data is re-written.  
> This is a totally different subject...

SEU are critical if they change the configuration of your device, but
uncritical in static devices with proper protection (eg. ASIC with
TMR).
I thought more about single event effects with permanent impact on the
device like wire degrading due to ESD or critical failures in your
power supply (or heavy ion in radiation environment).
Just the kind of error that's a bit to weak to instantly kill your
device but strong enough to have an permanent influence.
These failures might be very seldom, but maybe just because they are
so hard to detect?

bye Thomas

Article: 65208
Subject: Re: Soft failures (?) 9536XL
From: "Josep Duran" <j.duran@nospamteleline.es>
Date: Thu, 22 Jan 2004 09:53:05 +0100
Links: << >>  << T >>  << A >>
Thank you Peter,

"Peter Alfke" <peter@xilinx.com> escribió en el mensaje
news:400F2439.EC57ADB0@xilinx.com...
> The XC9536XL is a Flash-based CPLD.  Different from an SRAM-based FPGA,
> you do not reconfigure it just by cycling Vcc. The CPLD would need a
> fresh in-system programming operation, which is not automatic nor
> happens by accident.


 Yes. That part I understand.


> So, what might have happened is that your design got into an illegal
> state, out of which it cannot excape, but which did not affect the
configuration.
>

This was my first thought, I double checked the state machine, and I don´t
think there is a problem there.


> A more far-fetched explanation is based on the fact that a small part of
> the Flash-based configuration actually gets transferred into internal
> latches (like in an FPGA), which of course might get upset, and that
> would be fixed by cycling Vcc.

This is the part I am actually concerned. Could a noisy or poorly decoupled
Vcc be the source of the problems. How far-fetched explanation is this ? Is
it really possible ?

If I read the configuration through the JTAG port, do I get the
internal-actual-RAM configuration, or the Flash configuration ?


Or should I be looking for a bad solder point or other more mechanical
explanation ?


Josep Duran









Article: 65209
Subject: Re: References to good PCI boards and some newbie questions - please help!
From: "mikegw" <mikegw20@hotmail.spammers.must.die.com>
Date: Thu, 22 Jan 2004 19:56:59 +1100
Links: << >>  << T >>  << A >>


> 2. Do we have to buy a license to PCI core in order to use the board?
> I mean we are not going to modify any of the PCI interface functions.
> For all we care, PCI could have been implemented in a dedicated chip
> on our dev boards...
>
> Thanks all in advance for your responses!
>
 OK I know %$&$ all about the black arts but www.opencores .com looks like a
good place for free IP cores.

Back to lurking.....

Mike



Article: 65210
Subject: Anybody has any experience with Tarari Content processor?
From: valery@biozak.com (Valery)
Date: 22 Jan 2004 01:09:46 -0800
Links: << >>  << T >>  << A >>
Hi,

Tarari (an Intel spin-off) has released a new FPGA-based PCI board
that they feature on their site at:
http://www.tarari.com/products-highperformance.html

We are thinking of using it in our project and would be very
interested to hear any feedback.

Thanks,
Valery.

Article: 65211
Subject: Xilinx Spartan3 Timing Problems - Whats about the chips
From: "itsme" <itsme@gmx.de>
Date: Thu, 22 Jan 2004 10:29:02 +0100
Links: << >>  << T >>  << A >>
Hi all,
I am actually trying to switch a virtex2 project to spartan3. While
implementing the design I got several timing errors. One reason is that the
timing parameter "CLK to valid Data on Pad" (Tiockon). The data sheet of
virtex2 gives a value of 3.51ns. The value for spartan3 is 5.865ns - which
is much higher!!! . I got this value for spartan3 from Timing Analyzer
(Vers. 6.1.03i). In the newest datasheet of the spartan3 the chapter
"switching characteristics" is still quite empty.
So I really wonder what the XILINX guys do. Selling a chip without timing
specs? Is the spartan3 really much slower than the Virtex2?
Any comments? Any Spartan3 Users?



Article: 65212
(removed)


Article: 65213
Subject: Re: xilinx 70% tracking rule
From: guillerodriguez@terra.es (guille)
Date: 22 Jan 2004 02:44:26 -0800
Links: << >>  << T >>  << A >>
"Paul Leventis \(at home\)" <paul.leventis@utoronto.ca> wrote in message news:<7gKPb.46671$lGr.8430@twister01.bloor.is.net.cable.rogers.com>...
> I don't know whether 70% is the correct number or not, as it depends on many
> things and on how sophisticated the timing model was for the "maximum"
> numbers in the first place.  But here are a few other phenomena to add to
> the laundry list:
[...]

Interesting! Thanks for your input.

This 70% figure was for Xilinx CPLDs. What would be a good estimation
for Altera devices?

Does Altera document tracking properties for their devices? (either
'officially' in datasheets, or in application notes). Just curious.

> 
> But this is why FPGA companies have timing modeling and characterization
> groups, and part of why FPGAs are slowly taking over the world (or so I hope
> :-) -- imagine having to worry about all this stuff when doing your ASIC?

I can imagine :)

Guillermo Rodriguez

Article: 65214
Subject: Xilinx old development tool
From: claudio.tavoni@transport.alstom.com (Claudio)
Date: 22 Jan 2004 02:57:36 -0800
Links: << >>  << T >>  << A >>
Hi,
I have to modify an hold XC3042 project, developed in 1993 using XACT
4.12.
Actually I have only the LCA design files, the Orcad schematics and
the MCS programming file.

I am searching a copy of the old tool XACT 4.12 and a way to transport
this project to the XC3042A component.

Anyone can help me on this?

Regards
Claudio Tavoni

Article: 65215
Subject: Re: Synthesis of Loops
From: Bochumfrau@gmx.de (Bochumfrau@gmx.de)
Date: 22 Jan 2004 03:06:00 -0800
Links: << >>  << T >>  << A >>
Dear Mr,

Why is it better to avoid the unsigned library?
Is there a special reason ?
Is the use compiler dependant "bad" ?


Let's assume the following assignment:

i := conv_integer(l_vector);

...

When I do not include the unsigned library I get the error message:
"Object cannot be indexed because it has integer type rather than
array type".

So how can I make the same assignment when only using
the 1164 and arith library?

Rgds
Eva

> 
> One minor point:
> 
> > library ieee;
> >
> > use ieee.std_logic_1164.all;
> > use ieee.std_logic_arith.all;
> > use ieee.std_logic_unsigned.all;
> 
> Best to avoid this.  std_logic_unsigned is not pretty.
> std_logic_arith or numeric_std will do a better and
> clearer job for anything you are likely to need.
>

Article: 65216
Subject: Re: OT: liability insurance
From: russelmann@hotmail.com (Rudolf Usselmann)
Date: 22 Jan 2004 03:17:16 -0800
Links: << >>  << T >>  << A >>
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<aYKPb.14422$si4.11688@newssvr25.news.prodigy.com>...
> "Blake Henry" wrote:
> 
> > what's involved in getting the P.E. moniker
> 
> In the interest of accuracy (not criticism), "P.E." is not a moniker, which
> means "nickname".
> 
> "PE" stands for "Professional Engineer".  A Google search using that phrase
> reveals a world of information on the subject.

Gee, and here I was thinking Ray is a Private Eye on the
side ! ;*)

Cheers,
rudi               
========================================================
   ASICS.ws   ::: Solutions for your ASIC/FPGA needs :::
..............::: FPGAs * Full Custom ICs * IP Cores :::
FREE IP Cores -> http://www.asics.ws/  <- FREE EDA Tools

Article: 65217
Subject: Re: Synthesis errors?
From: "John Adair" <newsreply@loseinspace.co.uk>
Date: Thu, 22 Jan 2004 12:57:06 -0000
Links: << >>  << T >>  << A >>
I have used a lot of the synthesisers out there and I have had errors with
all of them at one time or another. I have usually tackled them in the way
you describe. Usually I have found particular constructs to be the issue and
generally avoid the ones that cause problems. Generally the best way to find
the bugs is in a post synthesis simulation. Do this ideally with a self
checking testbench that you can run on a spare machine in the background. It
can be a long process on a big design.

To reduce the long synthesis/simulation times consider using modular
synthesis and simulation. Some tools will do this automatically for you.
Using this approach you can virtually ignore "good" modules and look for
problems in the modules you have actually changed either by design or
synthesis. I hope to have a article on the cheap and cheerful approach to
this in our TechiTips page either this month or next.

John Adair
Enterpoint Ltd.

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.


"Ken Morrow" <junk@not_morro.co.uk> wrote in message
news:wmDPb.26583$qx2.3022656@stones.force9.net...
> Hi,
>
> I have recently had lots of incorrectly synthesised logic with the
> synthesiser I am using.
> My latest design occupied approx 20% of a "6 million gate" FPGA, and had a
> total of 5
> incorrectly synthesised parts (which took some finding).
>
> Can anyone recommend any synthesisers which do not suffer from this sort
of
> problem?
>
> The synth takes approx 1 hour to synth this (much quicker than most of my
> "large" designs), and timing far
> exceeds the requirements as the clock frequency is low.
>
> If anyone is interested, the sort of errors I was getting were:-
>
> A connection between 2 components was simply not made. An input to the
> second component was hardwired to '0'.
> Tried the very latest version of the same synth and the problem went away.
>
> The following problems were seen in the latest version:-
>
> OUT_DATA <= IN_DATA & "0";
> synthesised to
> OUT_DATA <= "0" & IN_DATA;
> put this in a clocked process and it synthesised correctly.
>
> OUT_DATA <= 2**IN_DATA;
> had OUT_DATA(0) hardwired to '1'.
> replaced with a case statement and it synthesised correctly
>
> if X = -1 then
>   OUT_DATA <= IN_DATA;
> elsif X= 1 then
>   OUT_DATA <= 0 - IN_DATA;
> elsif X=0 then
>   OUT_DATA <= 0;
> else
>   OUT_DATA <= 0 - IN_DATA;
> end if;
> had OUT_DATA=0 when X=-1
> put calculation of 0 - IN_DATA in a separate clocked process, and it
> synthesised correctly.
>
>
> An inferred ROM which synthesised correctly in an earlier version of the
> synthesiser, now infers a ROM filled with zeros.
> I worked around this by adding a reset to cause the ROM function to be
built
> from logic. This greatly increased
> the size, but this is not a problem for the particular design.
>
> I tried synthing the rogue pieces of code standalone, and they were
synthed
> correctly (apart from the ROM).
>
> Thanks,
>
> Ken,
> Morrow Electronics Limited,
> Milton Keynes,
> UK.
>
> kenm@morro.co.uk without the m after my name otherwise it will not be
> delivered.
>
>
>



Article: 65218
Subject: Verilog 2001 indexed part select in XST 6.1.3?
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Fri, 23 Jan 2004 00:02:19 +1100
Links: << >>  << T >>  << A >>
Hi,

Does anyone know if XST 6.1.3 supports the "indexed part select"
feature of Verilog 2001?  (It's in section 4.2.1 of the LRM.)

The Xilinx documentation states explicitly that it does support this
feature, yet when I try to use it, I get this error message:

ERROR:Xst:850 - foo.v line 134: Unsupported .

Example code:

reg [7:0] bar;
wire [31:0] foo;

genvar j;
generate
    for (j=0; j<8; j=j+1) begin : label
        always @(posedge clk)
            // error on next line:
            bar[j] <= &foo[4*j +: 4];
    end
endgenerate

Is there something special I have to do to enable 2001 support?

Thanks,
Allan.

Article: 65219
Subject: Virtex II Pro, powerpc 405 and ucOSII
From: Mancini Stephane <nospam@nospam.nospam>
Date: Thu, 22 Jan 2004 14:41:32 +0100
Links: << >>  << T >>  << A >>
Hi,
Is there anybody ou there who tried to run the real time OS ucOSII on a
virtex II platform ?
Have you tried different OS ?
I know that some Virtex II Pro kits comes with Linux as embedded OS but
I'm wondering if it's not too heavy for fast real time systems with
dedicated hardware parts (such as image processing, etc ...). What kind of
experience do you have with Virtex  II Pro and different OS ?
How do you manage the use of hardware peripherals (IO, computing
ressources, etc ...)
 Thanks a lot for your help

Stephane

Article: 65220
Subject: Re: Trouble using ChipsCope Pro with MicroBlaze
From: arkagaz@yahoo.com (arkaitz)
Date: 22 Jan 2004 05:45:57 -0800
Links: << >>  << T >>  << A >>
> What version of EDK and ChipScope are you using?

EDK 6.1 SP1
ChipScope Pro 6.1

Regards,

Arkaitz.

Article: 65221
Subject: Post-Place & Route simulation with MicroBlaze
From: arkagaz@yahoo.com (arkaitz)
Date: 22 Jan 2004 06:03:46 -0800
Links: << >>  << T >>  << A >>
Hi all,

I have a design where MicroBlaze isn't the top level of it.

I have simulated the behavioral model with ModelSim SE 5.6f and it
works fine but when I implement and download to the FGPA it doesn't
work, so now I want to simulate the Post-Place & Route model too see
if there's any timing wrong.

Due to my MicroBlaze desing isn't the top level, XPS doesn't allow me
generate the behavioral model, so I have to do it manually. That's the
way I have done the behavioral model simulation.

So I have a Project Navigator design with various components which one
of them is the MicroBlaze designed in XPS. In the testbench I use a
configuration block where I assign the code that needs to be inside
the blockram of MicroBlaze.
Since MicroBlaze isn't my top level this configuration block has the
next aspect:

configuration testbench_conf of system_tb_system_vhd_tb is
  for behavior
    for uut1 : top_level
      for structure
        for uut2: mb_blaze
          for structure
            for all: instr_mem_wrapper use configuration
work.instr_mem_conf;
            end for;
	  end for;
	end for;
      end for;
    end for;
  end for;
end testbench_conf;


The problem comes here. When I ask ISE to simulate the P&R model it
generates a file called "top_level_timing.vhd" which hasn't got any
hierarchy, so obvioulsy the configuration block generates some
compilation errors.

Is there any other way to assign the contents of the instruction set
to the  blockram of MicroBlaze?

Any other idea to avoid this error?

I am not used to working with configuration blocks, so the solution
might be obvious.

Thanks in advance, 

Arkaitz.

Article: 65222
Subject: Re: WTD: info on AMD palce22v10
From: Ralph Malph <noone@yahoo.com>
Date: Thu, 22 Jan 2004 09:43:49 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Ralph Malph wrote:
> >
> >   I have seen several startup FPGA
> > companies look good and then fail.  This even includes large companies
> > like Motorola.
> 
> Here is a partial list of major companies that introduced FPGAs, and
> then gave up:
> 
> Motorola (never got out of the starting gate, relied on external software...)
I don't know that it was the software that killed this product.  They
were using NeoCad which was pretty successful (at least technically) for
the other vendors they supported.  

> Intel (sold it to Altera, who then canned it quietly)
This line was second sourced by Cypress.  I can only assume that Altera
did not want to cooperate with Cypress and did not feel the need for
second sources.  

> NSC (disappeared quietly)

> AMD (sold it to Lattice)
PLDs only AFAIK.  Still being made.  It was sold off not because it was
failling, but because it was successful and AMD needed cash to keep the
CPU business running.  

> ATT (sold it to Lattice)
ATT never wanted to be a significant player.  They developed the ORCA
line to get telecoms to migrate to their ASICs.  Can't say how well that
worked.  

> T.I. ( stopped being second source to Actel)
I don't remember then selling FPGAs or similar, they did CPLDs.  TI did
a complete makeover and decided that they were all about DSP in
telecoms.  They sold off everything that was not a key technology and
bought a lot of stuff that was.  

> Toshiba (never really made it)
I never even heard of them. 

> Cypress (?)
Still there.  I can't say how much market share they have, but they are
selling product still.  

 
> The moral of the story is that you survive as an FPGA manufacturer only
> when you are totally dedicated to that product line, which is true for
> Xilinx, Altera, Lattice, Actel, Quicklogic and some small start-ups.
> The Big Guys usually find it easier to make their money on other products.

You forgot Philips who's product line you bought (or at least part of
it).  But being solely a PLD vendor does not guaranty success.  There
are any number of PLD makers that have gone by the wayside, several of
which were bought by Xilinx, some by Altera and others got swallowed up
by the remaining players.  

Heck, even the FPGA software companies are not immune to being swallowed
up.  The current Xilinx tools are just the latest version of NeoCad
software I belive.  

I think there is something else that is required to make it in the
FPGA/PLD world.  But I think the biggest factor is just that it is a
limited market and unless you are getting 10%+ market share, it is not
worth the commitment.  So a shakeout to four or five players was
inevitable.

Article: 65223
Subject: Re: Synthesis of Loops
From: <jonathan.bromley@doulos.com>
Date: Thu, 22 Jan 2004 15:09:28 -0000
Links: << >>  << T >>  << A >>
<Bochumfrau@gmx.de> wrote in message
news:17b83bf3.0401220306.3bfbe0ed@posting.google.com...

> Why is it better to avoid the unsigned library?

std_logic_vector is simply a collection of std_logic
bits.  The std_logic_unsigned package gives std_logic_vector
a new meaning (unsigned binary) that can be confusing, and
if you want to use signed numbers in the same design it
will become very difficult.

On the other hand, std_logic_arith defines two new data
types SIGNED and UNSIGNED, with the *same definition* as
std_logic_vector.  Using this, you can be very clear about
what you are trying to do.  numeric_std is even better,
because it is properly standardised by IEEE and it has a
more complete set of functions and operators.

> Let's assume the following assignment:
>
> i := conv_integer(l_vector);
>
> ...
>
> When I do not include the unsigned library I get the error message:
> "Object cannot be indexed because it has integer type rather than
> array type".

i := conv_integer( unsigned(l_vector) );

std_logic_vector and unsigned have the same definition, so they
are "closely related" and you can convert from one to the
other by using the type name as if it were a conversion function.
The vector<->integer conversions work between integer and
SIGNED or UNSIGNED data.
--
Jonathan Bromley




Article: 65224
Subject: Re: Soft failures (?) 9536XL
From: Ralph Malph <noone@yahoo.com>
Date: Thu, 22 Jan 2004 10:27:25 -0500
Links: << >>  << T >>  << A >>
Josep Duran wrote:
> 
> Thank you Peter,
> 
> "Peter Alfke" <peter@xilinx.com> escribió en el mensaje
> news:400F2439.EC57ADB0@xilinx.com...
> > The XC9536XL is a Flash-based CPLD.  Different from an SRAM-based FPGA,
> > you do not reconfigure it just by cycling Vcc. The CPLD would need a
> > fresh in-system programming operation, which is not automatic nor
> > happens by accident.
> 
>  Yes. That part I understand.
> 
> > So, what might have happened is that your design got into an illegal
> > state, out of which it cannot excape, but which did not affect the
> configuration.
> >
> 
> This was my first thought, I double checked the state machine, and I don´t
> think there is a problem there.

Illegal states have to do with combinations of your state FFs that are
not accounted for in your machine.  Or if you have more than one machine
and have not accounted for all the state combinations you can get into
trouble.  Sometimes two machines interact in a way that they need to be
considered one machine.  Make sure you have a bubble in your state
diagram that cooresponds to every possible state encoding, then there
are no "illegal" states.  Also account for all combinations of inputs at
every state.  


> > A more far-fetched explanation is based on the fact that a small part of
> > the Flash-based configuration actually gets transferred into internal
> > latches (like in an FPGA), which of course might get upset, and that
> > would be fixed by cycling Vcc.
> 
> This is the part I am actually concerned. Could a noisy or poorly decoupled
> Vcc be the source of the problems. How far-fetched explanation is this ? Is
> it really possible ?

Yes, noise on the Vcc can cause trouble for any design that has volital
storage, state machine or not.  Your state FFs can be corrupted by noise
on Vcc.  


> If I read the configuration through the JTAG port, do I get the
> internal-actual-RAM configuration, or the Flash configuration ?
> 
> Or should I be looking for a bad solder point or other more mechanical
> explanation ?



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