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 76725

Article: 76725
Subject: Re: Open source FPGA EDA Tools
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 09 Dec 2004 16:38:43 -0500
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:
> 
> rickman wrote:
> 
> >   This has been discussed
> > many, many times here and I still don't see any open source tools that
> > are worth using.
> 
> You probably use a lot of open source tools allready
> - spice
> - espresso (which is part of ISE, IIRC)
> - gcc (which is part of EDK)
> - tcl (which is part of allmos every EDA tool around that does not use a
> lisp dialect instead)

I find that I have to pay a lot of money for most of my tools and they
don't provide any source.  In fact, they expressly forbid me from
reverse engineering the tools.  

Are those the tools that you meant?  

-- 

Rick "rickman" Collins

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

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

Article: 76726
Subject: Re: Software controllable clock generator, Xilinx Virtex-II
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 09 Dec 2004 16:45:30 -0500
Links: << >>  << T >>  << A >>
Stephen Williams wrote:
> 
> I believe I know the answer to this, but I just want to check around
> in case I missed something.
> 
> I have an FPGA design where I'm taking an existing frame grabber
> board that we make and turning it around to make a CameraLink
> camera simulator. It works and I can even select the camera clock
> speed from a set of 8 values I precompiled.
> 
> However, I find I now want to be able to gradually ramp up the
> clock speed to see where our receiver boards start failing. My
> set of 8 frequencies span 85MHz to 16MHz. I would really rather
> be able to select frequencies from the range of 20-85MHz in 1MHz
> increments. The duty cycle of the output clock must be no worse
> then 60/40 for the ChannelLink transmitter chip, which has a PLL
> to think of.
> 
> I think I'm SOL and the best I can do is use as many DCM devices
> as I can, divide the results by 1/2/3/4 and use lots of BUFGMUX
> devices to select from that set of clocks and divided clocks. In
> other words, extend what I've already done until I run out of
> applicable resources. Besides being icky, that doesn't actually
> get me many clocks, not to mention the limited number of BUFGMUX
> devices to make a mux tree of clocks.
> 
> So is there a way that I'm missing for getting a single software-
> selectable output clock with a nearly 50/50 duty cycle ranging
> from 20 to 85MHz? On an XC2V3000-4?

I don't know much about the DCMs, but if you can use a 1 MHz ref, you
should be able to use a PLL with a divider in the feedback loop to
generate any multiple of 1 MHz between 43 and 85 MHz.  Then the output
can be divided down to many other frequencies including all the
multiples of 1 MHz below 43 MHz.  Will the DCM accommodate a 1 MHz ref
and 43 to 85 MHz output?  

-- 

Rick "rickman" Collins

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

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

Article: 76727
Subject: Re: Open source FPGA EDA Tools
From: "Hans" <hansydelm@no-spam-ntlworld.com>
Date: Thu, 09 Dec 2004 22:18:54 GMT
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message 
news:41B75EE9.91C61428@yahoo.com...
> markets.  This results in lots of updates and lots of bugs.  (BTW
> Mentor, are you *ever* going to fix the bug where Modelsim crashes
> randomly for no special reason???)

Sorry I can't resist it :-), but have you send them a testcase? do they know 
what is causing it? can you reproduce the crash? have you tried 6.0b? I am 
not trying to give a lecture since I have been cursing some of their 
&^£%=&( tools as well but I do know that debugging a piece of code as 
complex as Modelsim/NCSim/Aldec etc must be an absolute pig. Most if not all 
EDA companies will quickly bring out a patch release if you find a serious 
bug since this is their bread and butter. Your Modelsim can't be crashing 
randomly for no reason unless your PC is being hit by high energetic 
particles :-) If you can't send your source code them consider sending them 
an obfuscated version, and/or a compiled version (using the -nodebug if 
required) and/or set up and NDA, run your code on another PC, another OS, 
try using the command line version (vsim -c). Write a bit of Tcl which loops 
around your testbench repeatedly, then during the test read your mail, play 
some MP3 etc and see if this might be affecting Modelsim. Alternatively, get 
one of the Modelsim FAE's to visit you and sit next to you for a day while 
you re-run your testbench, you are(?) paying maintenance for it :-)

Back to debugging my code :-(

Hans





Article: 76728
Subject: Re: Getting Started With Simple Sound Synthesis
From: Mark McDougall <msmcdoug@no.spam.iinet>
Date: Fri, 10 Dec 2004 09:38:32 +1100
Links: << >>  << T >>  << A >>
Dave wrote:
> I'd like to create a sound synthesizer along the lines of a *very*
> simplified Commodore SID chip.  Any tips on how to get started?

<http://www.fpga.nl/index.html?jester.html>


-- 
|              Mark McDougall                | "Electrical Engineers do it
|         <http://to be announced>           |   with less resistance!"

Article: 76729
Subject: Re: Open source FPGA EDA Tools
From: Adam Megacz <adam@megacz.com>
Date: Thu, 09 Dec 2004 14:44:19 -0800
Links: << >>  << T >>  << A >>

BTW, has anybody compiled a bibliography on hardware evolution?  I'd
like to read through a big stack of papers on it all at once to try to
get up to speed.

  - a

Thomas Womack <twomack@chiark.greenend.org.uk> writes:
> In article <N7r*F0IBq@news.chiark.greenend.org.uk>,
> Thomas Womack  <twomack@chiark.greenend.org.uk> wrote:
>>In article <ljy8g7r1ho.fsf@troy.dt.e-technik.uni-dortmund.de>,
>>Marius Vollmer  <marius.vollmer@uni-dortmund.de> wrote:
>>
>>>What is missing, in my opinion, is not 1 million lines of code with a
>>>half-assed, half-open license.  We need complete and unencumbered
>>>documentation of the hardware, the way we have it for general purpose
>>>CPUs like IA-32, PowerPC, etc.  If there is a need for Free Software,
>>>it will then appear.  Maybe GOSPL provides these docs.
>>
>>We had something quite close to that, I _believe_, for the XC4000
>>series; I believe that's why those were the chips used in the amazing
>>evolution-of-hardware experiments in 1996 or so.
>
> Sorry, I meant XC6216 here. The December 1996 paper describes the device
> used as a prototype; I'm not sure what became of that range.
>
> http://www.cogs.susx.ac.uk/users/adrianth/ices96/node2.html
>
> is the paper, worth reading.
>
> Tom

-- 
I wrote my own mail server and it still has a few bugs.
If you send me a message and it bounces, please forward the
bounce message to megacz@gmail.com.  Thanks!

Article: 76730
Subject: Re: Verilog Book Recommendation
From: "Gabor" <gabor@alacron.com>
Date: 9 Dec 2004 14:48:49 -0800
Links: << >>  << T >>  << A >>
There are several good threads on comp.lang.verilog

A book I've found useful as a reference is:
The Verilog Hardware Description Language

by Thomas & Moorby


Article: 76731
Subject: Re: Getting Started With Simple Sound Synthesis
From: "Jeroen" <jayjay.1974@xs4all.nl>
Date: Fri, 10 Dec 2004 00:02:12 +0100
Links: << >>  << T >>  << A >>

"Dave" <apple2ebeige@yahoo.com> wrote in message
news:1102617329.116082.44050@c13g2000cwb.googlegroups.com...
> I'd like to create a sound synthesizer along the lines of a *very*
> simplified Commodore SID chip.  Any tips on how to get started?
> Thanks.
>
> -Dave
>

There's an article floating around somewhere on the Net describing the
implementation details of the SID (an interview with the original designer).

Basically, it's very simple. First, you need a NCO (Numerically Controlled
Oscillator) to produce a waveform. A NCO is nothing but a simple counter
that's incremented with a constant at a fixed rate. By changing this
constant you can change the frequency of the waveform. Usually the counter
is 24 bits, and the waveform is created from the top 8 bits, which can be
used as an index to a sample-table (a crude form of resampling). In the SID,
for a square wave, the top bit is used as output; for a saw wave, the top 8
bits; for a triangle wave 7 of the 8 topbits are used, and these are
followed by a XOR gates to invert the bits when the top bit is set. After
these, a simple R2R ladder that acts as DAC which is followed by an
amplifier and a filter.

This same NCO approach can also be used for the envelopes, but I think in
the SID, this was all analogue stuff using resistor, capacitors and
comparators.  I believe the amplifiers were simple CMOS switched resistor
ladders, as were the filters.

I think you could all the digital stuff in a smallish FPGA; coupled with
some analogue components it would make a well reverse-engineered SID. Forget
all noise defying PCB practises for the final touch. Attempting to it do it
completely digitally means you have to design-in its flaws too.

But you don't want to do a complete SID; all you need is a simple NCO, which
is only a few lines of VHDL. What will it interface to?

Jeroen



Article: 76732
Subject: Re: how to speed up my accumulator ??
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 09 Dec 2004 23:14:49 GMT
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:41B8C572.661C916@yahoo.com...
> PFD means Phase-Frequency-Detector?

Ayup.

> I believe you said that the digital phase detectors are not very
> linear.  Are you saying that there are *no* good detectors?  What if a
> digital phase detector were connected to analog current sources so that
> the pullup and pulldown were balanced?  Would that be linear enough?  I
> don't think that would be hard to design.

One example of a linear phase detector is an XOR to provide a center level
at 90 degree phase shift with nonlinearities as one approaches +/- 0.25 UI
of jitter with the circuit giving up in the "other" 180 degrees of phase.
I'd worry about implementing an XOR-type PFD in an FPGA because of problems
not only with jitter but with feedthrough from other frunctions in the FPGA
on the Voh and Vol levels.

One PFD I used about 10 years ago that appeared to have good specs was the
Analog Devices AD9901 which also produced a voltage output rather than the
charge pumps we tend to be more familiar with.



Article: 76733
Subject: Re: Open source FPGA EDA Tools
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 09 Dec 2004 18:27:48 -0500
Links: << >>  << T >>  << A >>
Hans wrote:
> 
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:41B75EE9.91C61428@yahoo.com...
> > markets.  This results in lots of updates and lots of bugs.  (BTW
> > Mentor, are you *ever* going to fix the bug where Modelsim crashes
> > randomly for no special reason???)
> 
> Sorry I can't resist it :-), but have you send them a testcase? do they know
> what is causing it? can you reproduce the crash? have you tried 6.0b? I am
> not trying to give a lecture since I have been cursing some of their
> &^£%=&( tools as well but I do know that debugging a piece of code as
> complex as Modelsim/NCSim/Aldec etc must be an absolute pig. Most if not all
> EDA companies will quickly bring out a patch release if you find a serious
> bug since this is their bread and butter. Your Modelsim can't be crashing
> randomly for no reason unless your PC is being hit by high energetic
> particles :-) If you can't send your source code them consider sending them
> an obfuscated version, and/or a compiled version (using the -nodebug if
> required) and/or set up and NDA, run your code on another PC, another OS,
> try using the command line version (vsim -c). Write a bit of Tcl which loops
> around your testbench repeatedly, then during the test read your mail, play
> some MP3 etc and see if this might be affecting Modelsim. Alternatively, get
> one of the Modelsim FAE's to visit you and sit next to you for a day while
> you re-run your testbench, you are(?) paying maintenance for it :-)

You are making a lot of assumptions.  This has been a problem I have
seen personally for the last four years on many different versions of
Modelsim and many different computers.  My coworkers in another company
also saw this problem and explained to me that it was a known bug in
Modelsim that was caused by a memory leak.  

I am just a dumb engineer who finds that one in 30 times as I recompile
a design and start to reload it, the Modelsim window disappears and I
have to open a new one only to find my last edited modules need to be
recompiled again.  I seriously doubt that it is related to my design in
any way (unless my style is really that bizarre) or my computer(s) or if
it has to do with how long the window has been open or how many times I
have reloaded the same files.   I just know it crashes more than I would
prefer.  

Has no one else seen this?  

-- 

Rick "rickman" Collins

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

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

Article: 76734
Subject: Re: Atari 10-in-1 Joystick
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Thu, 09 Dec 2004 23:49:15 GMT
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@case2000.com> wrote in message 
news:cp8vfm$vo$04$1@news.t-online.com...
> "Hendra" <u1000393@email.sjsu.edu> wrote in message
> news:1102573360.598385.97830@c13g2000cwb.googlegroups.com...
>> Has anyone seen Atari 10-in-1 Joystick?
>> www.walmart.com/catalog/product.gsp?product_id=2233972

> as those products are deep low priced they do have an ASIC inside not 
> FPGA.
> made in china.
> at 18.77USD end user price it is not possible to have FPGA based product.
> not yet, the FPGA prices are not so down!
> BTW in Germany the same thing costs 34 EURO !!
>
> I think the Atari in joystick is made by that guy who had a webpage about
> the 2600 in FPGA, he never released any design files and went commercial.
> The commodore-in-joystick is designed by and girl named Jeri who also
> designed C1 reconfigurable computer, but then obviously decided there is
> more money in joystick business.

Is this a 2600 in a joystick or an 800?

The 800 is a descendant of the 2600 in many ways, but significantly 
different in others.

I suspect from the number of other gaming things-on-sticks that they may 
have produced a platform that can emulate many others, i.e. an emulator 
on-a-stick. This is practical in today's technology. If it only has to 
emulate one machine, and doesn't have to run under a bloated OS like 
windows, it gets a lot easier as a task. An ARM chip would probably be up to 
the job, since they are used in some Intel's latest embedded CPU chips 
(under a new name to save Intel's pride).


For example,a mate of mine ported a game boy emulator onto a mobile phone 
CPU.


The amount of work involved in designing 20 such gaming products 
individually in FPGA would be enormous.


I'm finding it plenty of work getting the 800 alone into an FPGA.
Currently dual-porting the system bus between the CPU and the VDU sections.
Originally it was just the RAM bus, but the ANTIC may need to access ROM as 
well.

K.






Article: 76735
Subject: Re: Software controllable clock generator, Xilinx Virtex-II
From: Stephen Williams <spamtrap@icarus.com>
Date: Thu, 09 Dec 2004 15:54:26 -0800
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
 >
 >
 > Stephen Williams wrote:
 >
 > (snip)
 >
 >> However, I find I now want to be able to gradually ramp up the
 >> clock speed to see where our receiver boards start failing. My
 >> set of 8 frequencies span 85MHz to 16MHz. I would really rather
 >> be able to select frequencies from the range of 20-85MHz in 1MHz
 >> increments. The duty cycle of the output clock must be no worse
 >> then 60/40 for the ChannelLink transmitter chip, which has a PLL
 >> to think of.

 > If you start from a higher frequency, and use the divide by 1.5, 2.5,
 > etc. circuits that Peter Alfke has shown in some Xilinx notes, you
 > should be able to get pretty many frequencies in that range.
 > Do the frequencies need to be integer multiples of 1MHz?
 >
 > -- glen
 >

Can you point me to those APP notes? Fast divide by N.5 may help
indeed, but I can't find a da[r]ned thing on the Xilinx web site.

I figure that if I used clock dividers to get 85MHz and 84MHz,
I would need a phase accumulator accurate to 140pS. i.e.

   7.14GHz / 84 == 85MHz,
   7.14GHz / 85 == 84MHz, ...

which gets me the precision I want at the high end (and more
then I need at the low end) but an absurd FX frequency.

Or if I started with 340MHz (Which is still more then I can get
out of a -4 DCM)

   340MHz / 4 == 85.0MHz,
   340MHz / 5 == 68.0MHz,
   340MHz / 6 == 56.7MHz
   340MHz / 7 == 48.6MHz
   340MHz / 8 == 42.5MHz
   340MHz / 9 == 37.8MHz
   340MHz /10 == 34.0MHz
   340MHz /11 == 30.9MHz, ...

I can get more accuracy then I have now (which I can fill in
with another DCM and dividers) but 255MHz is more realistic:

   255MHz / 3 == 85.0MHz
   255MHz / 4 == 63.8MHz
   255MHz / 5 == 51.0MHz
   255MHz / 6 == 42.5MHz
   255MHz / 7 == 36.4MHz
   255MHz / 8 == 31.9MHz
   255MHz / 9 == 28.3MHz, ...

which makes a large gap of frequencies in the high end of my
desired range. I should be able to fill in these gaps with more
DCM devices with different (without common integer multiple!)
frequencies divided down. This was my original plan. With 3 DCMs
and some frequency dividers, I can get pretty good coverage at
the low end, with sparse (but adequate) coverage at the high end.

I guess I was hoping for a mathematical miracle to clean up my
tangled web of DCMs, BUFGMUX's and frequency dividers.

Boy, would a software controllable DCM be nice here. Unfortunately,
I ain't got a V4, I got what I got, a VirtexII, and the slow speed
grade at that.
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."


Article: 76736
Subject: Re: Software controllable clock generator, Xilinx Virtex-II
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 09 Dec 2004 16:05:58 -0800
Links: << >>  << T >>  << A >>


Stephen Williams wrote:

(snip regarding generating a variety of different clocks
from a small number of DCMs.)

> Can you point me to those APP notes? Fast divide by N.5 may help
> indeed, but I can't find a da[r]ned thing on the Xilinx web site.

http://www.xilinx.com/xcell/xl33/xl33_30.pdf

> I figure that if I used clock dividers to get 85MHz and 84MHz,
> I would need a phase accumulator accurate to 140pS. i.e.
> 
>   7.14GHz / 84 == 85MHz,
>   7.14GHz / 85 == 84MHz, ...
> 
> which gets me the precision I want at the high end (and more
> then I need at the low end) but an absurd FX frequency.

> Or if I started with 340MHz (Which is still more then I can get
> out of a -4 DCM)

But only 170MHz with the half frequency dividers.

>   340MHz / 4 == 85.0MHz,
>   340MHz / 5 == 68.0MHz,
>   340MHz / 6 == 56.7MHz
>   340MHz / 7 == 48.6MHz
>   340MHz / 8 == 42.5MHz
>   340MHz / 9 == 37.8MHz
>   340MHz /10 == 34.0MHz
>   340MHz /11 == 30.9MHz, ...

So they don't need to be integers.

Note that the relative frequency difference is smaller
at the higher frequencies if you keep the 1MHz increment.

20MHz to 21MHz is a 5% increase, so is 80MHz to 84MHz.

If you only need steps that are at most 5%, and not
required to be integers then I think it works with
a reasonable number of dividers and DCMs.

-- glen


Article: 76737
Subject: Re: Adder Tree Placement
From: Ray Andraka <ray@andraka.com>
Date: Thu, 09 Dec 2004 19:08:31 -0500
Links: << >>  << T >>  << A >>
You can speed it up a bit more by keeping the adders close together and pipelining
the inputs from the BRAMs.  Carry chains are typically the worst case paths, so
the trick is to put the ff's driving the carry chain physically as close to the
carry chain as you can get them.  Put the adders in every other slice column and
the pipeline registers in the columns in between for the maximum performance.

Kevin Neilson wrote:

> Ray Andraka wrote:
> > Well, if you must use a tree (more on that in a minute), then your best bet
> > is to include RLOCs for the adders.  You get reasonable performance by
> > placing the first level in every other slice column and then placing the
> > next levels in every other vacant column until you reach the root.
> > "Reasonable" depends on the depth of the tree and your clock speed of
> > course.  It starts losing performance at 3 levels or so, because of the
> > progressively longer routes.  You can make up the speed by adding pipeline
> > registers at the cost of real-estate.
> >
> > In the case of an FIR filter, however, you don't need a tree.  Instead, push
> > part or all of the tap delay through the coefficient multiplies so that you
> > can connect the adders in a linear array (ie daisy chained), absorbing the
> > delays into the adder registers.  That gives you all nearest neighbor
> > connections, and if you do it right, the latency is actually less than a
> > tree.  The cost is if you need to clock enable it, your control task is much
> > more complicated.
> >
> Your suggestion on tree layout is exactly what I was looking for.  It
> seems my tree that is floorplanned like a tree isn't the best plan.
>
> You are right about the transpose FIR architecture, though.  I have
> become convinced that that is the best choice because of the ease of
> layout.  I will be able to place the adders right next to the BRAMs in
> the column and the datapaths will be nice and short.
> -Kevin

--
--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: 76738
Subject: Re: Spartan3 Block RAM from WebPACK
From: "nshimizu" <nshimizu@ip-arch.jp>
Date: Thu, 09 Dec 2004 19:09:20 -0500
Links: << >>  << T >>  << A >>
Hello,

I also want to use Block RAM with data2mem tool without success. I uses
Spartran-3 Development Kit with ISE webPack.

> If you have processor code in the ROM, you can also use > a .bmm file
> and the data2mem tool to let you change the code without > recompiling
> the whole design

Would you please instruct more detail?

I made a .bmm file as:

ADDRESS_BLOCK mainmem MEMORY [0x000:0x7ff]
 BUS_BLOCK
 mainMem_Mram_mcell_inst_ramb_0 [7:0] OUTPUT=mcell.mem;
 END_BUS_BLOCK;
END_ADDRESS_BLOCK;

I made 2kb of mcell.mem start with 
@00
c3 3d 00 00 00 00 00 00 ed 4d 00 00 00 00 00 00 
ed 4d 00 00 00 00 00 00 ed 4d 00 00 00 00 00 00 
...

After then, I invoked data2bram with:

data2bram -bm mcell.bmm -bt swsystem.bit -bd mcell.mem -o b new     

It generate new.bit without any error messages but
new.bit is just the same as swsystem.bit.
Then it may not updated at all but just copied, I think.
The name in the BUS_BLOCK is extracted from floorplan editor, and I
generated the name in ADDRESS_BLOCK.

Would anybody give me any suggestion?

Regards,
Naohiko



Article: 76739
Subject: Re: Getting Started With Simple Sound Synthesis
From: "Dave" <apple2ebeige@yahoo.com>
Date: 9 Dec 2004 16:09:34 -0800
Links: << >>  << T >>  << A >>
Jeroen wrote:
>
> Basically, it's very simple. First, you need a NCO (Numerically
Controlled
> Oscillator) to produce a waveform. A NCO is nothing but a simple
counter
> that's incremented with a constant at a fixed rate. By changing this
> constant you can change the frequency of the waveform. Usually the
counter
> is 24 bits, and the waveform is created from the top 8 bits, which
can be
> used as an index to a sample-table (a crude form of resampling). In
the SID,
> for a square wave, the top bit is used as output; for a saw wave, the
top 8
> bits; for a triangle wave 7 of the 8 topbits are used, and these are
> followed by a XOR gates to invert the bits when the top bit is set.
After
> these, a simple R2R ladder that acts as DAC which is followed by an
> amplifier and a filter.
>
...
>
> But you don't want to do a complete SID; all you need is a simple
NCO, which
> is only a few lines of VHDL. What will it interface to?
>
> Jeroen

Thank you, Jeroen, that was very helpful.  The synthesizer will
interface to a homebrew CPU in my FPGA.

Do I recall SID had a noise source as well?  Would a LFSR be suitable?
Thanks.

-Dave


Article: 76740
Subject: What is the purpose of the 2 registers on A and B in the V4 Extreme DSP?
From: "Kevin Brown" <kbrown_home@hotmail.com>
Date: 9 Dec 2004 16:18:39 -0800
Links: << >>  << T >>  << A >>
In the extreme DSP slice there are two registers before the
multiplication on each of the A and B inputs. Does anyone know why you
would need 2 registers before the multiplication?

At first I thought it may be a register similar to the one in a
MULT18x18s, but changing the number of registers on A and B from 1 to 2
had no effect on timing. Also it wouldn't make sense since A and B are
individually selectable to have 0,1, or 2 registers.

-Kevin


Article: 76741
Subject: Re: how to speed up my accumulator ??
From: Ray Andraka <ray@andraka.com>
Date: Thu, 09 Dec 2004 19:35:35 -0500
Links: << >>  << T >>  << A >>
Moti,

There are a couple things you can do.  First off, if you look closely at
an accumulator, the feedback from a particular bit only affects that bit
and bits with greater significance.  That suggests that you can perform
partial sums and then combine the results.  One simple trick that takes 2x
the resources of the straight accumulator is to break your 32 bit
accumulator into two 16 bit accumulators.  The carry out of the first gets
registered and fed into the carry in of the second.  Note that by doing
that, the second follows the first by a clock cycle, so you need to delay
the upper half of the addend (the new value getting added, not the
feedback value) by a clock cycle using a register so that it arrives at
the upper half of the accumulator at the same time as the registered carry
from the lower half.  Likewise, the lower half sum output (but not the
feedback) has to be delayed by a clock cycle to align it with the upper
half sum.  On the surface, that would seem to permit almost double the
clock speed (and it did in older Xilinx devices), however in Virtex
devices the propagation time to get on and off the carry chain is an order
of magnitude larger than the bit to bit propagation times, so in reality
the gain from this trick is rather small until you get into truely huge
accumulator widths.

A more usable trick requires a little more attention to the design
implementation.  The carry chains are typically the critical path (mostly
because the times to get on and off the chain are on par with the LUT
delay).  You can't do much anything about the delay in the carry chain or
the intrinsic delay for getting on and off the chain.  You can, however,
minimize the delays on the signal connecting to the carry chain input.
This means making sure that you only have one level of logic (ie,
flip-flops are directly driving the LUTs that feed the carry chain), and
you need to make sure those flip-flops are placed in close proximity to
the carry chain (ideally either in the same CLB, or on an adjacent CLB so
you can use the direct connect wires).  Note that the automatic placement
is not particularly good at making sure those flip-flops are placed this
way.  The accumulator feedback doesn't need to be pipelined because it is
connecting back around to the same bit (assuming you've reduced the logic
to 1 level), which means it is already pipelined as much as it could be.
You may need to pipeline the new addend path in order to achieve the one
level of logic at the accumulator and keep the driving flip-flops in
adjacent slices, but that is OK as it doesn't affect the accumulator
operation.

You normally should use active high resets because that is what is native
to the fpga.  In this case, I don't think it is affecting your timing
however, because it is an asynchronous reset.  Had it been a syncrhonous
reset, some synthesizers would have inserted a gate between the carry
chain and the register, which would have added an extra LUT delay to the
input path rather than inverting the resetn signal.

Hope this helps


Moti Cohen wrote:

> Hello all,
> I've a design that contains a NCO (Numerically controlled oscillator).
> The NCO consists of a 32'bit accumulator. when i write the accumulator
> straight forward like this -
>
> process (clk,resetn)
> begin
>         if resetn = '0' then
>                 accumulator     <= (others =>'0');
>         elsif clk'event and clk ='1' then
>                 accumulator     <= accumulator + inc_value;
>         end if;
> end process;
> Fout <= accumulator (accumulator'high);
>
> the maximum frequency I can achive for 'clk' is ~ 150 MHz (spartan 3).
> I need it to work in ~200 MHz so I figured out that some pipelining is
> needed but I dont know how to do it because of the accumulator
> feedback. Maybe someone here can explain it to me or even give me a
> code example (which will be great).
>
> Thanks in advance, Moti.

--
--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: 76742
Subject: Re: how to speed up my accumulator ??
From: Ray Andraka <ray@andraka.com>
Date: Thu, 09 Dec 2004 19:50:08 -0500
Links: << >>  << T >>  << A >>
Moti,

Another trick for NCO's that will double the speed, assuming you are careful
about how you update the tuning word (phase increment) is to use two
accumulators running clock enabled on every other clock.  One is initialized
with 0, the other is initialized with the phase increment value, and then both
are incremented by 2x the phase increment on every other clock.  This allows
two clock periods for the accumulator carry to propagate, and you get the
current and next phase out at the same time on every other clock.  A 2:1 mux
switching at the clock rate selects the output from the two accumulators on
alternate clocks.

I've used this trick also for cases where the mixer it is driving can't run at
the full clock rate (I usually use a CORDIC rotator there, see my XCELL
article about that).  In that case, you use duplicate copies of the mixer, one
for even samples and the other for odd samples.  The phase for both is
incremented by 2x the sample phase increment, with one offset by 1x the phase
increment.

I don't think you'll have to resort to this to get to 200MHz with a
Spartan3,however.  I'm pretty sure careful floorplanning combined with making
sure you have just one level of LUT logic in the critical path (new addend
through carry chain to accumulator register) will get you 200MHz with a very
comfortable margin at 32 bits.
--
--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: 76743
Subject: Re: Getting Started With Simple Sound Synthesis
From: "Jeroen" <jayjay.1974@xs4all.nl>
Date: Fri, 10 Dec 2004 02:21:44 +0100
Links: << >>  << T >>  << A >>

"Dave" <apple2ebeige@yahoo.com> wrote in message
news:1102637374.894620.303250@c13g2000cwb.googlegroups.com...
> Jeroen wrote:
> >
> > Basically, it's very simple. First, you need a NCO (Numerically
> Controlled
> > Oscillator) to produce a waveform. A NCO is nothing but a simple
> counter
> > that's incremented with a constant at a fixed rate. By changing this
> > constant you can change the frequency of the waveform. Usually the
> counter
> > is 24 bits, and the waveform is created from the top 8 bits, which
> can be
> > used as an index to a sample-table (a crude form of resampling). In
> the SID,
> > for a square wave, the top bit is used as output; for a saw wave, the
> top 8
> > bits; for a triangle wave 7 of the 8 topbits are used, and these are
> > followed by a XOR gates to invert the bits when the top bit is set.
> After
> > these, a simple R2R ladder that acts as DAC which is followed by an
> > amplifier and a filter.
> >
> ...
> >
> > But you don't want to do a complete SID; all you need is a simple
> NCO, which
> > is only a few lines of VHDL. What will it interface to?
> >
> > Jeroen
>
> Thank you, Jeroen, that was very helpful.  The synthesizer will
> interface to a homebrew CPU in my FPGA.
>
> Do I recall SID had a noise source as well?  Would a LFSR be suitable?
> Thanks.

Actually, the SID used a LFSR for that :))





Article: 76744
Subject: Re: Getting Started With Simple Sound Synthesis
From: Jeff Cunningham <jcc@sover.net>
Date: Fri, 10 Dec 2004 03:29:19 GMT
Links: << >>  << T >>  << A >>
Thomas Womack wrote:
> The VGA interfaces I've seen all have something of the form
> 
> --pin1 -- R  --|
>                |
> --pin2 -- 2R --+---monitor
>                |
> --pin3 -- 4R --|
> 
> so maybe something like that would produce a really, really cheap
> DAC for the output stage.


Xilinx has an app note for a sigma-delta converter design that just 
requires an external R and C. Also companies like AKM and Crystal have 
CD quality converters that are just a couple bucks and pretty easy to use.

Jeff


Article: 76745
Subject: XPS errors
From: "Jerry" <nospam@nowhere.com>
Date: Thu, 9 Dec 2004 22:40:33 -0500
Links: << >>  << T >>  << A >>
My design is mixed, Microblaze in VHDL and the application in verilog with
CORE memory FIFOs and Dual Ports. I used CORE Gen for
the memory blocks. XPS cannot link my memory blocks when doing a bit stream
generate. If I do a place and route in ISE for just my
app (verilog) it runs just fine. Anybody else having this problem?

Thanks




Article: 76746
Subject: Re: Open source FPGA EDA Tools
From: Jeff Cunningham <jcc@sover.net>
Date: Fri, 10 Dec 2004 03:51:03 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
> I am just a dumb engineer who finds that one in 30 times as I recompile
> a design and start to reload it, the Modelsim window disappears and I
> have to open a new one only to find my last edited modules need to be
> recompiled again.  I seriously doubt that it is related to my design in
> any way (unless my style is really that bizarre) or my computer(s) or if
> it has to do with how long the window has been open or how many times I
> have reloaded the same files.   I just know it crashes more than I would
> prefer.  
> 
> Has no one else seen this?  

I've used modelsim PE for about 5 years and XE for about 3 under windows 
and I've found them to be rock solid reliable. I can't ever remember 
them crashing out from under me like you describe.

Jeff


Article: 76747
Subject: Re: Open source FPGA EDA Tools
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Fri, 10 Dec 2004 04:07:23 GMT
Links: << >>  << T >>  << A >>
Hi - 

On Fri, 10 Dec 2004 03:51:03 GMT, Jeff Cunningham <jcc@sover.net>
wrote:

>rickman wrote:
>> I am just a dumb engineer who finds that one in 30 times as I recompile
>> a design and start to reload it, the Modelsim window disappears and I
>> have to open a new one only to find my last edited modules need to be
>> recompiled again.  I seriously doubt that it is related to my design in
>> any way (unless my style is really that bizarre) or my computer(s) or if
>> it has to do with how long the window has been open or how many times I
>> have reloaded the same files.   I just know it crashes more than I would
>> prefer.  
>> 
>> Has no one else seen this?  
>
>I've used modelsim PE for about 5 years and XE for about 3 under windows 
>and I've found them to be rock solid reliable. I can't ever remember 
>them crashing out from under me like you describe.
>
>Jeff

I've used ModelSim PE for about 5 years, too, and I get semi-frequent
(one time in, say, 50 seems about right) crashes, too.  The simulation
starts running normally, but at some point all of the ModelSim-related
windows disappear.  I restart the simulator, run the very same
simulation, and everything's jake.

This has happened across multiple versions of the simulator and on at
least two different PCs, under W2K.  It's not a show-stopper, but it
is very annoying.  I haven't reported it to ModelTech because I have
no reliable way of reproducing it.

Bob Perlman
Cambrian Design Works


Article: 76748
Subject: Re: how to speed up my accumulator ??
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Fri, 10 Dec 2004 17:58:47 +1100
Links: << >>  << T >>  << A >>
On Thu, 09 Dec 2004 23:14:49 GMT, "John_H" <johnhandwork@mail.com>
wrote:

>"rickman" <spamgoeshere4@yahoo.com> wrote in message
>news:41B8C572.661C916@yahoo.com...
>> PFD means Phase-Frequency-Detector?
>
>Ayup.
>
>> I believe you said that the digital phase detectors are not very
>> linear.  Are you saying that there are *no* good detectors?  What if a
>> digital phase detector were connected to analog current sources so that
>> the pullup and pulldown were balanced?  Would that be linear enough?  I
>> don't think that would be hard to design.
>
>One example of a linear phase detector is an XOR to provide a center level
>at 90 degree phase shift with nonlinearities as one approaches +/- 0.25 UI
>of jitter with the circuit giving up in the "other" 180 degrees of phase.
>I'd worry about implementing an XOR-type PFD in an FPGA because of problems
>not only with jitter but with feedthrough from other frunctions in the FPGA
>on the Voh and Vol levels.
>
>One PFD I used about 10 years ago that appeared to have good specs was the
>Analog Devices AD9901 which also produced a voltage output rather than the
>charge pumps we tend to be more familiar with.

I made an error earlier - the mixer type phase detectors only have a
sinusoidal PD characteristic when fed with sine waves.  When fed with
square waves (such as from the output of an FPGA or divider) they have
performance basically identical to that of an XOR gate, with a
triangular PD characteristic.  An XOR gate is much cheaper and easier
to use than a multiplier, of course.
One can work around the Voh & Vol problems by using an external CMOS
gate fed from filtered supplies.

One disadvantage of the XOR gate (apart from the lack of frequency
discrimination) is that, at lock, at has a square wave on its output.
This results in reference spurs at the PLL output that can be
difficult to remove.  Since the square wave is predictable, it is
possible to come up with compensation schemes (e.g. by adding a fixed
duty cycle square wave of opposite phase) to reduce the level of the
spurs.

The AD9901 is basically an XOR gate with an added frequency
discriminator.

Regards,
Allan

Article: 76749
Subject: Re: Open source FPGA EDA Tools
From: Kim Enkovaara <kim.enkovaara@tellabs.com>
Date: Fri, 10 Dec 2004 09:35:07 +0200
Links: << >>  << T >>  << A >>
rickman wrote:

> Mentor, are you *ever* going to fix the bug where Modelsim crashes
> randomly for no special reason???)  I dont' see open source tools fixing
> any of this.  The current open source front end tools are still far

You need a testcase, fixing a bug where the description is "it crashes
sometimes" is impossible. Yes, Modelsim has bugs, but every one of the
ones I have found have been fixed in a reasonable time (usually
optimisation bugs). They have even added some optimisations for new classes
of structures just by asking and providing a good testcase.

It should not be impossible to do a testcase. I have done some testcases
even from 5+M gate designs where something is wrong in the SDF timing
model. Those are really hard bugs to debug. For example no testbench is
needed for a testcase, just use "vcd dumpports" functionality. There
are also engineering builds of Modelsim that can be used to debug the
crashes.

I have not seen any random crashes and I use Modelsim in quite a big
cluster for regression runs etc. And have been using M for many years.
One place where modelsim at least had problems was restart command.
After many restarts when the design structure changes enough it at least
crashed in the past. Also if wave window was used heavily during
simulation in versions <5.7 it quite often crashed.

But I have had similiar experiences with other simulators. Some of them are
even more crash prone. But they usually crash during the compilation
already :) Nothing is perfect.

--Kim



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