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 124100

Article: 124100
Subject: Re: microblaze toolchain compilation question
From: taco <tralalal@joepie.nl>
Date: Wed, 12 Sep 2007 09:26:14 +0200
Links: << >>  << T >>  << A >>
John Williams wrote:

> Hello Taco,
> 
> taco wrote:
>> hello all,
>> I'm trying to compile the microblaze-toolchain from source on a 64 bits
>> linux system, but got stuck. The source from the petalogix repository
>> doesn't compile. a first problem was solved with help of colleague:
>> a declaration error in 2 header files of binutils/gas (just wondering if
>> this is done on purpose by petalogix..).
> 
> I can assure you the source tarball you found on the PetaLogix website
> is the same as was used to build the gcc at that time.  It builds fine
> on a RHEL/CentOS 3 machine, such as the one I am using right now.
> 
> 
> Regards,
> 
> John

Hello john, 
are you sure? I just did everything again in a clean directory. Executing
do_everything results in:
/usr/local/microblaze/microblaze-toolchain-sources/srcs/binutils//gas/config/tc-microblaze.h:63:
error: array type has incomplete element type
and the compilation stops.
The solution is to move the struct relax_type from tc.h to as.h in
srcs/binutils/gas and remove the forward declaration from as.h. It's just a
simple order, but I assume that this also will not work on a RHEL system
without doing this unless your gcc compiler works different.
(a colleague running ubuntu had the same problem by the way)

After this modification the same script continues but stops again in the gcc
phase:
mkdir -p -- libgcc
mkdir -p -- bs
mkdir -p -- libgcc/bs
mkdir -p -- m
mkdir -p -- libgcc/m
mkdir -p -- bs/m
mkdir -p -- libgcc/bs/m
if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi
/usr/local/microblaze/microblaze-toolchain-sources/build/lin/bld_gcc/gcc/xgcc -B/usr/local/microblaze/microblaze-toolchain-sources/build/lin/bld_gcc/gcc/ -B/usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/bin/ -B/usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/lib/ -isystem /usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/include -isystem /usr/local/microblaze/microblaze-toolchain-sources/release/lin/microblaze/microblaze/sys-include -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc -I/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/. -I/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/../include   -DL_muldi3 -c /usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/libgcc2.c -o
libgcc/./_muldi3.o
/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/libgcc2.c:
In function `__muldi3':
/usr/local/microblaze/microblaze-toolchain-sources/srcs/gcc/gcc/libgcc2.c:461:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

Well, this one is perhaps more related with the compiler/64 bits
environment. so I changed do_all_gcc.csh with the -m32 flags and this gives
the already mentioned error (libgcc2.c compilation):
/tmp/ccYgSyAu.s: Assembler messages:
/tmp/ccYgSyAu.s:124: Error: operand must be absolute in
range -2147483648..2147483647, not -1042284544
If you've any idea, that would be very nice.
Taco



Article: 124101
Subject: Re: Uses of Gray code in digital design
From: David Brown <david@westcontrol.removethisbit.com>
Date: Wed, 12 Sep 2007 09:36:49 +0200
Links: << >>  << T >>  << A >>
richard.melikson@gmail.com wrote:
>>> They could be, but that would add latencies to the FIFO that
>>> are best avoided. ie why compromise the operation, when a Gray
>>> Code design will work better ?
>> It's more complicated than that.  Running a multi-bit value
>> through a synchronizer doesn't work if more than one bit changes.
>> Some of the bits might get there in time when others don't.
>>
>> If the data changes from 000 to 111, you might see
>> 001, 010, 100, 011, 101, or 110 for a cycle before
>> it settles.  (That's assuming it was stable at 000
>> for several cycles and then stays at 111 for several
>> cycles.)
> 
> Ah - this is a most important point, I think. So, you imply that if I
> want to share a counter between two clock domains, I can so a simple
> double FF synchronization on it if it's encoded in Gray, whilst for a
> normal counter I need a handshake protocol with a synchronized control
> signal ?
> I think I understand how this can make things faster.
> 

It's even better - with the Gray code, you don't need the FF 
synchronisation at all, as long as you are stepping up or down through 
the codes (it's a different matter for step machines that jump steps). 
The point is that whenever you look at the code as it passes from one 
value to the next, it is either in the old state or in the new state - 
there is nothing in between.  With a binary counter, you could see 
intermediary stages as different bits toggle with different delays. 
Synchronisation FF's have nothing to do with it.

Article: 124102
Subject: Re: Uses of Gray code in digital design
From: David Brown <david@westcontrol.removethisbit.com>
Date: Wed, 12 Sep 2007 09:45:47 +0200
Links: << >>  << T >>  << A >>
Andy wrote:
> On Sep 11, 4:42 am, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
>> Jonathan Kirwan wrote:
>>
>> <snip huge and informative post>
>>
>> I hope you copied-and-pasted a lot of that post rather than writing it
>> all yourself!
>>
>> I hadn't thought about using Gray code for communication, but it's a
>> really smart idea.  Supposing you want to send 10-bit data within a
>> 16-bit message.  All you need to do to send data "x" is to calculate:
>>
>> y = toGray16(x << 6)
>>
>> At the other side, you receive "z".  To get your best estimate for the
>> original "x", you calculate:
>>
>> x' = (fromGray16(z) + 0x1f) >> 6
>> xe = z - (x1' << 6)
>>
>> xe is the Hamming distance between the sent data (assuming the
>> corruption is not too bad, obviously) and the received data, while x' is
>> the nearest correct code.
>>
>> mvh.,
>>
>> David
> 
> Does that work?  While adjacent binary codes are always represented by
> single bit differences in gray, the converse is not true; single bit
> changes in gray are not necessarily adjacent codes in binary.
> 

No, it does not work :-(
Perhaps something can be made out of the idea, but it's back to the 
drawing board.

> Also, n-count changes in binary code are not necessarily represented
> by n-bit changes in gray.
> 
> Andy
> 

Article: 124103
Subject: [Nios II] How fast the cpu in Nios II can reach in the Cycone ?
From: lexluthor <hezhikuan2007@gmail.com>
Date: Wed, 12 Sep 2007 00:58:57 -0700
Links: << >>  << T >>  << A >>


Can it reach 100 DMIPS =A3=BF

I give the cpu 100MHz clk, and use the Fast Core.

There is a program:

void main()
{
    while(1)
    {
        IOWR_ALTERA_AVALON_PIO_DATA(PIO_0_BASE,  data++);
    }
}

The frequence of change of the outputs can reach 100 MHz?


Article: 124104
Subject: Re: Good VHDL reference?
From: xenix <lastval@gmail.com>
Date: Wed, 12 Sep 2007 08:12:07 -0000
Links: << >>  << T >>  << A >>
The one i am using and it is the first book have used to learn VHDL is
"VHDL for Designers" from Stefan Sjoholm and Lennart Lindh.



Article: 124105
Subject: Re: Xilinx core generator MIG module generates a slow timing for a DDR2 SDRAM controller
From: damicha@gmx.de
Date: Wed, 12 Sep 2007 01:17:35 -0700
Links: << >>  << T >>  << A >>
On 11 Sep., 16:07, "Sylvain Munaut <Some...@SomeDomain.com>"
<246...@gmail.com> wrote:
> Yes the generated timings are miscomputed ... They forgot to take
> several thing into account ...
> You can modify the _parameters.vhd file yourself and change the value.
> There is only
> 4 or 5 important ones.
> To redure the wtp and wr to their minimum I think you'll have to
> modify the _ddr2_controller.vhd file and force them ...
>
> To understant how to compute the delay, look at their state machine
> and how they use the value you specify.
>
>    Sylvain

Hello.

OK, my target FPGA is the Virtex5 (I forgot to mention that). The
designs generated by the core generator are different for Virtex5,
Virtex4 and Spartan3.
For the Virtex5 I found the timing calculations in the
mem_interface_top_V5_ctrl_0.vhd file.
There are some deviations between the comments and the code.
e.g. for tRP:

  -- TRP: PRECHARGE->COMMAND interval - 2
  constant TRP_CYC  : integer := (TRP/CLK_PERIOD) + 1;

When I change the calculation for TRP_CYC in the code like this:

  constant TRP_CYC  : integer := (TRP/CLK_PERIOD) - 2;

the tRP time will be shorter in the simulation (less clock cycles are
used).

This seems to be better but I'm not sure about the reason of the
original code. Maybe my "corrected" design with the new timing will
doesn't work with real hardware.

Is there any official information for my problem or has anybody a hint
for me?

thx DaMicha.




Article: 124106
Subject: Re: Uses of Gray code in digital design
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 12 Sep 2007 20:18:48 +1200
Links: << >>  << T >>  << A >>
Paul Keinanen wrote:
> On Tue, 11 Sep 2007 20:03:33 -0700, Mike Treseler
> <mike_treseler@comcast.net> wrote:
> 
> 
>>CBFalconer wrote:
>>
>>
>>>'synchronously' requires a clock driving everything.  Not avail.
>>
>>That depends on the application.
>>When a clock *is* available, the
>>state encoding style is irrelevant
>>to timing or function.
> 
> 
> If you have a counter, you usually feed it with a clock :-)
> 
> A ripple counter (7490 style) is more or less useless for decoding
> states at high speeds, since the decoding can be done only after the
> sum of the flip-flop propagation delays. 
> 
> In synchronous counter (such as 74196), each flip-flop "knows" in
> advance, if it should change state at the next count pulse, thus the
> delay is only as large as the propagation delay of a single FF. Some
> gating is required to decide, if the FF should change state at the
> next count pulse or not.

It gets murkier when you have to allow for finite routing delays,
and in the newest FPGAs routing delays can be significant.


> Since gating is required anyway for the counting, I don't see the
> point of using a Gray sequence instead of a simple 1-2-4-8 weighting.
> 
> For short sequences, the Johnston counter would be ideal, if you need
> to decode all states.

Yes, Johnson counters can be useful, and can decode glitch-free as well 
as Gray counters.
The simpler D-FF structure of Johnson counters means they
can often count faster than other counters. - but they need more
registers for a given modulus, so it's a trade-off.

-jg


Article: 124107
Subject: Re: FPGA Archives
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Wed, 12 Sep 2007 09:27:12 +0100
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> writes:

> How do you get messages from comp.arch.fpga archives?
>
> Google brings up headings that I may want to read, however,
> when I click on those headings I go to the archives that
> are listed by year and month.  There isn't a clear way
> to find the message that I wanted to read.
>

The way I used to do it is to use the browsers search within the page
funciton to find the words I originally told google to look for.
Nowadays, if I'm looking for stuff on c.a.f, I use the "Google groups"
interface to search for it (adding "group:comp.arch.fpga" to the text
I type into the search box, or use the advanced search).  

I still use GNUS to post though, no pointy-clicky for me :-)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 124108
Subject: Re: Address sensitive process, Xilinx virtex2pro
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 12 Sep 2007 10:15:17 +0100
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
news:13eebgov3qke76@corp.supernews.com...
> Add this:
>> my_proc: process (Bus2ip_Clk)
>> begin
>  if( Bus2ip_clk'event and Bus2ip_Clk='1') then
>>  if (Bus2ip_Addr = X"some address") then
>>  Bus2ip_Data <= X"FF00FF00";
>>  end if;
> end if ;
>> end process;
>>
>
>
Naah,
This is better.
> my_proc: process (Bus2ip_Clk)
> begin
  if rising_edge(Bus2ip_Clk) then
>  if (Bus2ip_Addr = X"some address") then
>  Bus2ip_Data <= X"FF00FF00";
>  end if;
end if ;
> end process;
>
HTH., Syms.



Article: 124109
Subject: Re: PCI byte enalbes in read cycles
From: Ben Jackson <ben@ben.com>
Date: Wed, 12 Sep 2007 04:20:42 -0500
Links: << >>  << T >>  << A >>
On 2007-09-11, A.D. <isd_mod@libero.ix> wrote:
> Hi all,
> I'm implementing a PCI interface in FPGA, but I'm stuck
> trying to figuring out what happens with byte enables in
> burst read cycles.

If there are no side-effects for reading the bytes, you can just return
them all.  Not many modern memory architectures are going to run faster
by reading anything smaller than a 32-bit word, anyway.

You might want to look at the PCI-X docs.  My vague recollection is that
the pipelining of BE (and a few other signals) changed in PCI-X and there
might be something that explains the change so as to enlighten you as to
the operation of "old" PCI.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 124110
Subject: Re: Quick question for an Altera wizard
From: Ben Jackson <ben@ben.com>
Date: Wed, 12 Sep 2007 04:24:54 -0500
Links: << >>  << T >>  << A >>
On 2007-09-10, Daniel S. <digitalmastrmind_no_spam@hotmail.com> wrote:
>
> I only use primitives for stuff that cannot be inferred.

I can send you code that makes a nice fifo out of SRL16s on a Xilinx part
(via inference, not with the coregen) and a huge mishmash of flops on an
Altera part...  If you use 10% of your FPGA you can be content to use
perfectly portable source code.  If you really need the best speed and
density, you're stuck with generated modules that sometimes don't map
well to other architectures.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 124111
Subject: Command line quartus_pgm very slow
From: Steven Derrien <sderrienREMOVE@irisa.fr>
Date: Wed, 12 Sep 2007 11:37:37 +0200
Links: << >>  << T >>  << A >>
Hi folks,

I have a question regarding the use of the command line quartus 
programmer tool under Linux. I have been using for a while, and I 
noticed that this latter one was *very* slow (10x) compared to the GUI
version.

It seems that the programmer hangs on somthing for 15 secodns or so 
before actually starting to download the bitstream. Does anybody on this 
newsgroup knows how to solve this issue ?

Thanks in advance,

Steven

Article: 124112
Subject: precision errors. microblaze vs matlab single precision... huh?
From: chriskoh <chrisdekoh@yahoo.com>
Date: Wed, 12 Sep 2007 03:27:56 -0700
Links: << >>  << T >>  << A >>
Hi all embedded gurus out there,
    I am working on an embedded platform using microblaze. I am
trying
to implement an algo, which does a inverse matrix function on the
microblaze (via C) and then port the results back to matlab.
   so this is the scenario.

1) matlab generates some numbers, passes them to microblaze via the
UART (ie. PC to UART)
2) microblaze will then generate the matrix, and then calculate its
inverse and do other stuff (dot product of matrices etc etc).
3) microblaze will then send the result back to PC via UART.


Ok..so here's the problem.
the result obtained differs from matlab's result (I coded the same
implementation also in matlab). the result obtained varies up to an
error of 1 decimal place!!!


How I tried to debug
1) step through the C code using the debugger for microblaze. (this
is
very cool tool).
2) at each step of the way, look at how the variables change for each
operation in the C code running on microblaze...and also observe how
the variables change in matlab


this is what I noticed
thinking it was due to matlab processing it in double precision, i
type cast the whole matlab routine in single precision. then I tried
to verify it again in the same way. And I get the same problem :(


can anyone help? As a result of this precision errors, the whole algo
fails to work. I am really not sure which one to trust now.


Would appreciate if anyone can help me on the same. The current
microblaze platform is using hardware FPU.


Chris


Article: 124113
Subject: Re: Command line quartus_pgm very slow
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 12 Sep 2007 13:12:30 +0200
Links: << >>  << T >>  << A >>
Steven Derrien <sderrienREMOVE@irisa.fr> writes:

> I have a question regarding the use of the command line quartus
> programmer tool under Linux. I have been using for a while, and I
> noticed that this latter one was *very* slow (10x) compared to the
> GUI version.

Might be a shot in the dark, but I've noticed that some of the Altera
command line tools have been running at a very low priority. Try to
run as:

nice -n -20 quartus_pgm ...

You probably have to be root in order to do that.

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 124114
Subject: Re: [Nios II] How fast the cpu in Nios II can reach in the Cycone
From: =?GB2312?B?R6iucnNraSBBZGFt?=
Date: Wed, 12 Sep 2007 14:05:09 +0200
Links: << >>  << T >>  << A >>
lexluthor pisze:
> 
> Can it reach 100 DMIPS £¿
> 
> I give the cpu 100MHz clk, and use the Fast Core.
> 
> There is a program:
> 
> void main()
> {
>     while(1)
>     {
>         IOWR_ALTERA_AVALON_PIO_DATA(PIO_0_BASE,  data++);
>     }
> }
> 
> The frequence of change of the outputs can reach 100 MHz?
> 

No. Take a look over assembler file. It's not a single instruction.
Additionaly NIOS need more than one clk cycle for instruction execution
( or maybe not)
But anyway you can add hardware extension for special request (like
parallel to serial hardware conversion)

Adam

Article: 124115
Subject: Re: Quick question for an Altera wizard
From: KJ <Kevin.Jennings@Unisys.com>
Date: Wed, 12 Sep 2007 05:29:56 -0700
Links: << >>  << T >>  << A >>
On Sep 12, 5:24 am, Ben Jackson <b...@ben.com> wrote:
> On 2007-09-10, Daniel S. <digitalmastrmind_no_s...@hotmail.com> wrote:
>
>
>
> > I only use primitives for stuff that cannot be inferred.
>
> I can send you code that makes a nice fifo out of SRL16s on a Xilinx part
> (via inference, not with the coregen) and a huge mishmash of flops on an
> Altera part...  If you use 10% of your FPGA you can be content to use
> perfectly portable source code.  If you really need the best speed and
> density, you're stuck with generated modules that sometimes don't map
> well to other architectures.
>
> --
> Ben Jackson AD7GD
> <b...@ben.com>http://www.ben.com/

I'd be interested in it if you don't mind.

KJ




Article: 124116
Subject: Re: Stratix III Memory usage efficiency
From: davew <David.Wooff@gmail.com>
Date: Wed, 12 Sep 2007 05:44:00 -0700
Links: << >>  << T >>  << A >>
On 11 Sep, 23:12, Mike Treseler <mike_trese...@comcast.net> wrote:
> davew wrote:
> > if I want
> > a 2720X18 memory (48960 bits), the wizard will construct one out of 9
> > 4096X2 memories (82944 bits) which is 60% efficient.
>
> > Does anyone have a strategy for getting more efficiency of usage out of
> > these blocks?
>
> Skip the wizards, write code, use synthesis.
>
> Quartus synthesis can do 4096x18 in 73728 bits.http://home.comcast.net/~mike_treseler/block_ram.pdfhttp://home.comcast.net/~mike_treseler/block_ram.vhd
>
>         -- Mike Treseler

Thanks Mike,
perhaps I'm asking a daft question but your example uses 9 M9K blocks
of a Stratix III which = 82944 bits or 73728 as you say if you
configure the M9K as 4096X2 = 8192 bits.  Your example uses all the
bits in the block so the utilisation is 100%.  My memory only utilises
60% of the bits but it could have been organised differently with a
little extra logic - I'm not suggesting that Quartus should be able to
work this out though - I don't think it can because it would involve
extra gates and the pipeline delays would be different.

In my solution, I used 6 M9K blocks configured as 512X18 and
multiplexed the outputs (BTW my memory is dual ported).  It also
required a decoder to provide individual we lines to each of the
blocks.  In other words it stacked the memory blocks in series rather
than in parallel at the expense of the extra logic.

I wondered if this was a common way of getting better utilisation or
if there was a better way.

Have I missed your point though?

DaveW.




Article: 124117
Subject: Re: clock skew problems
From: michel.talon@gmail.com
Date: Wed, 12 Sep 2007 12:44:30 -0000
Links: << >>  << T >>  << A >>
Hi,

I found the pin list, and all pins are named like .ICLK
The two pins which have a different name are inputs of two BUFGMUX.
It seems to be matching with my ISE warning  (  my_clock may have
excessive skew because 2 NON-CLK pins failed to route using a CLK
template ).
But there is something I don't understand.. I used BUFGMUX primitive
to avoid clock problems and to keep my_clock on the global clock
network.
Does it mean that I can't connect a clock on a BUFGMUX input ? so, how
can I do to multiplex clocks keeping my_clock on a global clock
network to avoid skew problems ?

Thanks by advance,

Best regards, Michel.

On 6 sep, 12:51, Joseph Samson <u...@not.my.company> wrote:
> michel.ta...@gmail.com wrote:
> > Hi all,
>
> > I've got a FPGA design with a lot of clocks!
> > ISE
> > gives me warnings :
> > Route:447  - CLK Net : my_clock may have excessive skew because 2 NON-
> > CLK pins failed to route using a CLK template. ( I've this warning for
> > a lot of others clock generated by combinatorial logics... )
>
> > My question is how can I locate the 2 NON-CLK pins
>
> Use FPGA Editor to open the routed design.
> Find the clock net and highlight it.
> Press F2, or select Edit -> Properties of Selected Items...
> Choose the 'Pins' tab.
> You will see a list of all the pins on that net.
> Scroll down the list until you find pins that don't have .CLK (or some
> variant like .ICLK1 or .CLKA) in their name.
>
> ---
> Joe Samson
> Pixel Velocity





Article: 124118
Subject: Re: Stratix III Memory usage efficiency
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Wed, 12 Sep 2007 15:54:41 +0300
Links: << >>  << T >>  << A >>
davew wrote:
> On 11 Sep, 23:12, Mike Treseler <mike_trese...@comcast.net> wrote:
>> Skip the wizards, write code, use synthesis.
>>
>> Quartus synthesis can do 4096x18 in 73728 bits.http://home.comcast.net/~mike_treseler/block_ram.pdfhttp://home.comcast.net/~mike_treseler/block_ram.vhd
>>
>>         -- Mike Treseler
> 
> I wondered if this was a common way of getting better utilisation or
> if there was a better way.
> 
> Have I missed your point though?

I guess the main point was that don't use the wizards to generate the
memories unless there is no other way (very exotic amount of ports
etc.).

It's wiser just to let the synthesizer to infer the memories. Then
the memories are usually portable to other architectures, and it's
easy in the tools to change how the memories are implemented with
attributes or synthesis settings.

The integrated synhesizers can infer most of the normal memory
structures. Synplify seems to be much better figuring out what
to infer even from quite convoluted code that does not
follow the example templates.

--Kim

Article: 124119
Subject: Re: Address sensitive process, Xilinx virtex2pro
From: Erik Anderson <erik.k.anderson@gmail.com>
Date: Wed, 12 Sep 2007 13:29:39 -0000
Links: << >>  << T >>  << A >>
Taking a guess, it looks like you are using Xilinx, and taking another
guess, you may have created your core using the Xilinx Create
Peripheral Wizard.

If you did, one thing to look out for is the USER_HIGHADDR.  Depending
on what options you choose int the Peripheral Wizard, in the core
wrapper file the USER_HIGHADDR could be being set with the following
line (syntax purposefully abbreviated).

USER_HIGHADDR : stl := C_BASEADDR or X"000000FF";

Which has the annoying effect of only allowing 256 byte addresses.  If
you are trying to read an address within your core above xFF, the IPIF
returns 0 for you.

In my cores, when I see this I always just change this line to read
USER_HIGHADDR : stl := C_HIGHADDR;

Hope this helps.

Erik


Article: 124120
Subject: VHDL Design Pattern Book
From: Erik Anderson <erik.k.anderson@gmail.com>
Date: Wed, 12 Sep 2007 13:37:12 -0000
Links: << >>  << T >>  << A >>
After reading http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/d33ee4b046fdbc83/3c6a335982d8fccd#3c6a335982d8fccd
I started to wonder if anyone has attempted to write a book on VHDL
design patterns.  Or for that matter HDL patterns in general.  I guess
I am looking for something in the same style as Design Patterns by
Gamma and etc, but for hardware.


Article: 124121
Subject: Re: VHDL Design Pattern Book
From: Steven Derrien <sderrienREMOVE@irisa.fr>
Date: Wed, 12 Sep 2007 15:59:20 +0200
Links: << >>  << T >>  << A >>
Hi, Eric

Erik Anderson a écrit :
> After reading http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/d33ee4b046fdbc83/3c6a335982d8fccd#3c6a335982d8fccd
> I started to wonder if anyone has attempted to write a book on VHDL
> design patterns.  Or for that matter HDL patterns in general.  I guess
> I am looking for something in the same style as Design Patterns by
> Gamma and etc, but for hardware.

There's a paper "Design Patterns for Reconfigurable Computing" by Dehon 
et al. published in 2004 in FCCM, here is a link to a pdf version

http://www.cs.caltech.edu/research/ic/pdf/despat_fccm2004.pdf

Regards,

Steven


Article: 124122
Subject: Re: Good VHDL reference?
From: "Dan K" <danielgkNOSPAM@visi.com>
Date: Wed, 12 Sep 2007 09:00:51 -0500
Links: << >>  << T >>  << A >>

"Eli Bendersky" <eliben@gmail.com> wrote in message 
news:1189574386.802346.152830@19g2000hsx.googlegroups.com...
> On Sep 11, 9:33 pm, n...@puntnl.niks (Nico Coesel) wrote:
>> It seems I have misplaced my VHDL book a long time ago and I can't
>> figure out where I left it. In short: I need a new VHDL book :-(
>>
>> Can anyone recommend a good generic VHDL reference? I'm not looking
>> for a book with a particular bias towards fpga design, asic design, or
>> simulation.
>>
>
> I've waded through my share of VHDL books, and Ashenden's (Designer's
> Guide) is by far the best of the pack.
>
> Eli
>
I'll second the Ashenden's (Designer's Guide) plug, but also add that I have 
both the Designer's Guide and "The Student's Guide to VHDL" by Peter 
Ashenden and I actually prefer the student's guide as it seems to have 
everything I need without having a lot of extra stuff I never use.  And its 
cheeper too!.

Dan 




Article: 124123
Subject: Re: Address sensitive process, Xilinx virtex2pro
From: Jeff Cunningham <jcc@sover.net>
Date: Wed, 12 Sep 2007 10:07:25 -0400
Links: << >>  << T >>  << A >>
 > sensitive to a given address

means to me:

> --my_proc: process (Bus2ip_Clk)
> my_proc: process (Bus2ip_Addr)

?

Article: 124124
Subject: Re: Stratix III Memory usage efficiency
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 12 Sep 2007 07:14:47 -0700
Links: << >>  << T >>  << A >>
davew wrote:

> Thanks Mike,
> perhaps I'm asking a daft question but your example uses 9 M9K blocks
> of a Stratix III which = 82944 bits or 73728 as you say if you
> configure the M9K as 4096X2 = 8192 bits.

Note that I didn't configure anything other
than the address and data widths. If I
compiled the same code using ise, some other block sizes
would be used.

> Your example uses all the
> bits in the block so the utilisation is 100%.

Your requirement is slightly over the 11 bit boundary
so I used 12 address lines. You may end up needing
that extra memory anyway.

> My memory only utilises
> 60% of the bits but it could have been organised differently with a
> little extra logic - I'm not suggesting that Quartus should be able to
> work this out though - I don't think it can because it would involve
> extra gates and the pipeline delays would be different.

That would be a custom, device-specific design.
If that's what I wanted to do, I would infer
multiple smaller rams and glue them together
in a wrapper entity.

> In my solution, I used 6 M9K blocks configured as 512X18 and
> multiplexed the outputs (BTW my memory is dual ported).  It also
> required a decoder to provide individual we lines to each of the
> blocks.  In other words it stacked the memory blocks in series rather
> than in parallel at the expense of the extra logic.

That strikes me as a lot of work to save three blocks.

> I wondered if this was a common way of getting better utilisation or
> if there was a better way.

I leave so much block ram unused, that
the thought never occurred to me.

> Have I missed your point though?

I guess my main point is that I have
a bad attitude about using vendor-specific wizards
when I don't have to.

          -- Mike Treseler



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