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 79300

Article: 79300
Subject: Re: ProAsic3 (PA3)
From: "limours" <jerome.fron@actel.com>
Date: Thu, 17 Feb 2005 01:31:52 -0500
Links: << >>  << T >>  << A >>
The problem you reported on the I/O register clear polarity is a real
problem in the Designer software (Thank you for pointing it out) and will
be fixed in the next service pack of the software.


Article: 79301
Subject: VGA core
From: "FAS3" <tortoisedundee@yahoo.com>
Date: Thu, 17 Feb 2005 01:52:15 -0500
Links: << >>  << T >>  << A >>
Hello:

Does anyone have a opb vga core for the MicroBlaze?

Thanks




Article: 79302
Subject: Re: PPC405 sleep?
From: Michael Lawnick <m.lawnick@kontron-applications.de>
Date: Thu, 17 Feb 2005 08:11:36 +0100
Links: << >>  << T >>  << A >>
Bo said the following:
> I am trying to put the PPC405 asleep on a VirtexIIPro ML310 Xilinx 
> development board and not have a lot of luck. I'm running VxWorks and have 
> written a little application that toggles an LED so that I know the task is 
> running. I've tried two methods--with drastically different results-- but 
> neither of which do everything I need.
> 
> First try:
> 
>  I loaded my app that toggles LEDs via a Tornado shell.
> 
> Spawn the LED toggler.
> 
> Note that via Tornado shell, I see LED toggler in the task list at an "i" 
> command. Note that via the serial shell, I cannot see LED toggler in the 
> task list at an "i" command.
Well, I'd expect you see it, but not with the expected symbolic name. As
you loaded the code via host shell, you'd need to include host sym table
sync to your target's image.

> 
> Disable PIT, so only a UART or network source interrupt will awaken me (ie 
> no sysClk/timer interrupts)
> 
> Put to sleep via  MSR[WE].  Observed LED quits toggle-- as expected.
> 
> Then, via a SERIAL shell, I type "i", and vxWorks awoke and printed the 
> tasks data as expected-but the LED toggler did not resume execution.
> 
How should it?
You disabled timer interrupt!

> Second try:
> 
> I moved all this code into UsrAppInit and then programmatically, spawned the 
> LED toggler. Wait a few secs (so I can observe LED on scope). Then Disable 
> PIT and put to sleep.
> 
> Now, I try to awaken the PPC405 via the serial connection. I cannot seem to 
> waken the PPC at all. If/when it wakens, the next line of code in usrAppInit 
> would have printed out an "Awoken" message--but I never see this happen.
> 
> Note that the Msr register is set to 0x00069200 to initiate the sleep-which 
> should set the sleep bits, and enable critical and external interrupts 
> (though the PIT as a possible feeder to External Interrupt has been disabled 
> via a write to TCR of 0x00040000...)
> 
> Someone else had mentioned to me the need for possible sync and orderly 
> execution before putting the PPC to sleep, so I added "sync, isync, and 
> eieio" code immediately prior to the set MSR[WE] bit, but this made no 
> difference. Any ideas?
> 
First action in your UART's ISR should be to re-enable timer interrupt.
This is a major device, VxWorks can't run without it properly.

HTH

-- 
Regards,
Mit freundlichen Grüßen,
Michael Lawnick

HTML-Mail is the first choice to distribute EMail-worms and -virii.
Back to the roots!

Article: 79303
Subject: Re: VGA core
From: Matthias Alles <alles@rhrk.uni-kl.de>
Date: Thu, 17 Feb 2005 09:19:10 +0100
Links: << >>  << T >>  << A >>
Hi!

> Does anyone have a opb vga core for the MicroBlaze?

I have one. However it is not generic at the moment. You would have to 
calculate the needed values for the timing-generation yourself (atm it 
uses a pixel clock of 21.5MHz). However I have problems with the 
bandwith of the OPB-Bus. It seems that it is too slow to deliver the 
needed video data. The best solution I think is to merge the VGA 
controller into the RAM controller.

Matthias


Article: 79304
Subject: binary constant divider theory
From: "SD" <sourabh.dhir@gmail.com>
Date: 17 Feb 2005 00:37:11 -0800
Links: << >>  << T >>  << A >>
Hi all,

I have two questions:

1. I implemented a binary constant divider in VHDL with my fixed
   point number system.The constant is 0.5. Its signed(1,7). one
   bit for the sign and the rest seven bits for the fraction part.
   All my values are
   between (1,-1). My divider works fine but my question is WHY
   does it work fine? It may sound funny but I dont fully
   understand the theory behind it. I just saw a pattern in
   calculations and wrote my code in VHDL. please help/advise?

ENTITY divider is
  PORT(    a  : IN  unsigned(7 DOWNTO 0);
           o  : OUT unsigned(7 DOWNTO 0));
END divider;
ARCHITECTURE behavior OF divider IS
BEGIN
o(7)<= a(7);
o(6)<= a(5);
o(5)<= a(4);
o(4)<= a(3);
o(3)<= a(2);
o(2)<= a(1);
o(1)<= a(0);
o(0)<= not a(6);
END behavior;



2. Whats the best way to get to know the combinational delay while
using the free Xilinx WebPack tool? When we
   synthesize the design, the synthesis report does give a "Maximum
combinational path delay ". Is that what I should
   be looking at or is it just an estimate??

Thanks in advance
Sourabh


Article: 79305
Subject: Re: binary constant divider theory
From: renjith <>
Date: Thu, 17 Feb 2005 00:47:00 -0800
Links: << >>  << T >>  << A >>
Hi SD u can do the timing analysis for ur design using Xilinx's Timing Analyzer. This tool gives a detailed description about the critical path covered on ur design.

Article: 79306
Subject: Re: FPGA programming newbie
From: =?ISO-8859-1?Q?Johan_Bernsp=E5ng?= <xjohbex@xfoix.se>
Date: Thu, 17 Feb 2005 10:39:08 +0100
Links: << >>  << T >>  << A >>
Clemens Reinrich wrote:
> Hello
>=20
> I have implemented a FSL core for the Microblaze processor. It is a ver=
y
> easy test programm, and now I wanna try to use chipscope to take a look=
 at
> the internal registers of my Core. I think this is achivable with Chips=
cope,
> so is there somewhere a useful tutorial which explains me step by step =
what
> I have to do to be able to read out data from my core? Would be very
> thankful for usefull tips
>=20
> Best Wishes
> Clemens
>=20
>=20
>=20

It shouldn't be any problem at all. Use ChipScope Inserter after=20
synthesis and before implementation of the system. In the inserter you=20
should be able to connect the ChipScope core to the signals of your core.=


After the insertion of the core in your system netlist you just continue =

the design flow with the ngdbuild, map, par, bitgen, bitinit and impact.

I did this over a year ago, and at that time I had to move some files=20
generated by the ngdbuild to the implementation directory manually.=20
Below is an example of the commandos I used at the command line.

ngdbuild -sd implementation/ -p xc2v1000fg456-6 -nt timestamp -bm=20
implementation/system.bmm -uc data/system.ucf system.ngo

mv ddr_v1_00_b_virtex2_async_fifo.ngo=20
implementation/ddr_v1_00_b_virtex2_async_fifo.ngo
mv system_ngdbuild.nav implementation/system_ngdbuild.nav
mv netlist.lst implementation/netlist.lst
mv system.bld implementation/system.bld
mv system.ngd implementation/system.ngd

map -o implementation/system_map.ncd implementation/system.ngd=20
implementation/system.pcf

par -w -ol 2 implementation/system_map.ncd implementation/system.ncd=20
implementation/system.pcf

bitgen -w -f etc/bitgen.ut implementation/system

bitinit system.mhs -pe microblaze_0 microblaze_0/code/xmdstub.elf  -bt=20
implementation/system.bit -o implementation/download.bit

impact -batch etc/download.cmd

I don't know if this is of any help for you, but it might point you in=20
the right direction at least...



--=20
-----------------------------------------------
Johan Bernsp=E5ng, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------

Article: 79307
Subject: Re: Xilinx RPM in Makefile?
From: "a0-0b" <e-mail@andrew-brown.org>
Date: 17 Feb 2005 02:20:52 -0800
Links: << >>  << T >>  << A >>
Surely someone know how? There are bound to be command line options for
those implementing core gen functions?


Article: 79308
Subject: thread programming support in EDK?
From: "Jack" <JEmoderatz@yahoo.com>
Date: 17 Feb 2005 03:08:01 -0800
Links: << >>  << T >>  << A >>
hi all

I am starting practicing the multi-thread programming and a simple
example is working in desktop linux machine.
After trying in same example in EDK with microblaze (standalone), the
error message is

----
TestApp/src/TestApp.c : in function 'main':
TestApp/src/TestApp.c : 12 'pthread_t' undeclared
...
----

so it seems that EDK tool chain does not have pthread library and
header file.

How can we fix this problem ? Anyone have experience on this?


Article: 79309
Subject: 3.3V device programmable with 5V?
From: "Mouarf" <mouarf@chezmoi.fr>
Date: Thu, 17 Feb 2005 12:52:39 +0100
Links: << >>  << T >>  << A >>
hello all,

I've made a prototype board with an XC9572XL CPLD (3.3V). I'm currently 
building a parallel programming cable version II 
(?)(http://www.xilinx.com/support/programr/files/0380507.pdf)

I wonder wether I can set Vcc to 3.3V or not since parallel port I/O are 5V 
(but logic levels migth be tolerant).

If not, is the XC9572XL device programmable with a 5V powered cable?


Does anyone have the schematics of a parallel cable version III or IV?

Thanks for your help. 



Article: 79310
Subject: Re: binary constant divider theory
From: "Andrea Sabatini" <andrea@dapdesign_N_O_S_P_A_M_.com>
Date: Thu, 17 Feb 2005 13:21:03 +0100
Links: << >>  << T >>  << A >>
Sourabh,

it seems that you are actually performing a multiplication by 2 ( x / 0.5 = 
x * 2) and so the sign remains the same band the other bits are one position 
left shifted. to me it seems that your module should not give proper result 
if a(6) = 1 and even the value of o(0) should be always zero but this 
happens only if a(6) = 0... so now i am a bit confused...

does it give any clue?

andrea



Article: 79311
Subject: Re: See the next high-wire act, this time on power consumption
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Thu, 17 Feb 2005 12:32:36 +0000
Links: << >>  << T >>  << A >>
On Wed, 16 Feb 2005 07:33:08 -0800, Austin Lesea <austin@xilinx.com>
wrote:

>Paul,
>
>I agree.
>
>Austin

Now I've seen everything.

- Brian

( p.s. thanks to you both for the discussions!)

Article: 79312
Subject: Re: 2 microblaze access same BRAM ?
From: "Elinore" <elinore2005@yahoo.fr>
Date: 17 Feb 2005 04:33:36 -0800
Links: << >>  << T >>  << A >>
hi

Final --: questions are about the suggestions above- multi-programming
and FSL.
I find FSL is a point2point link in the product specification.
It seems that two approaches are totally different.
Does EDK support such a multi-programming? If yes, in which way? How
can we emulate the shared memory hardware and software (for example,
threaded programming) in Xilinx tool?

2 microblazes with FSL and shared memory ; this looks very exotic and
it seems that we still have two independent main() routines.
In any case, it will be interesting that one main() routine
transperently describe  an algorithm and two microblazes coorperate
each other.

By the way, thankyou very much, G=F6ran


Article: 79313
Subject: Re: Xilinx RPM in Makefile?
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Thu, 17 Feb 2005 12:34:10 +0000
Links: << >>  << T >>  << A >>
On 16 Feb 2005 06:51:44 -0800, "a0-0b" <e-mail@andrew-brown.org> wrote:

>Does anyone have any idea how i can generate the UCF required for an
>RPM without manually running the floorplanner?  (so i can create the
>RPM from a makefile)  the floorplanner does not apparently have a
>"batch mode" despite a reference to a <script_file> in the help - which
>is apparently not supposed to be there!
>I've got a hierarchical design builtup of many sub-blocks implemented
>as RPMs, so for each design change i need to rebuild the RPMs and
>recreate the full chip.
>A nightmare if i have to run the floorplanner interactively!

I'm not sure I see what you need.

If you know what you want to put in the UCF, you can generate it in a
text editor or from scripts. Similarly, you can convert an absolute
placement("LOC=SLICE_X0Y0") UCF file to relative placement ("RLOC=X0Y0)
in a text editor via global find/replace, and it'll work. Relocating
elements should be possible with PERL scripts or similar.

There are bugs in the flow, which should go away in the 7.1 tool release
... meanwhile, it is good to occupy the lower left corner of the
rectangle surrounding your RPM with one of its components ( i.e. an "L"
or  "E" shape is good, "T" or "+" will give unexpected results ), and
place RPMs on even X and Y locations (otherwise the mapper may move them
around).

Having got an RPM ("RLOC") UCF, you can create the RPM .NGC from the
command line with NGCbuild. (An example command line will be found in
the .blc report file created when you built the RPM in the floorplanner)

So it is all possible without the floorplanner ... though the
floorplanner is probably the easiest way to make some kinds of changes.

Or am I misunderstanding what you are trying to do?

- Brian

Article: 79314
Subject: Re: Any Altera FIFO not a power of 2?
From: "Kenneth Land" <kland_not_this@neuralog_not_this.com>
Date: Thu, 17 Feb 2005 06:49:08 -0600
Links: << >>  << T >>  << A >>

"Rene Tschaggelar" <none@none.net> wrote in message 
news:42122fbb$0$3410$5402220f@news.sunrise.ch...
> Kenneth Land wrote:
>
>> Hello,
>>
>> I'm having a hard time fitting the two fifo's I need into my StratixI 
>> device (EPS10) because of the power of 2 requirement on the depth.
>>
>> Are there any fifo variants that lift this requirement?
>>
>> Right now we're instantiating 2 sc_fifo's within a AHDL file.  (I need 
>> two 3600 word fifos which would fit, but have to use two 4096 word fifos 
>> which do not fit)
>>
>> I'm aware of the FIFO Partitioner, but would like to avoid this if 
>> possible.
>
>
> Would it be thinkable to have multiple FIFOs behind each other ?
> EG a 2048 & 1024 & 512 ?
>
> Rene
> -- 
> Ing.Buero R.Tschaggelar - http://www.ibrtses.com
> & commercial newsgroups - http://www.talkto.net

Hi Rene,

How would this work?  A little latency wouldn't hurt.  Is it very tricky to 
stack fifo's?

Thanks,
Ken



Article: 79315
Subject: Re: Any Altera FIFO not a power of 2?
From: "Kenneth Land" <kland_not_this@neuralog_not_this.com>
Date: Thu, 17 Feb 2005 06:53:57 -0600
Links: << >>  << T >>  << A >>

"Gabor" <gabor@alacron.com> wrote in message 
news:1108496252.756870.206390@l41g2000cwc.googlegroups.com...
>
> Peter Sommerfeld wrote:
>> Hi Ken,
>>
>> I've done this before by writing my own fifo using the altsyncram
>> megafunction. altsyncram has a parameter MAXIMUM_DEPTH which allows
>> non-power-of-2 depths. Adding single-clock FIFO functionality (read
> and
>> write ptr management at a minimum) shouldn't be more than 20 lines of
>> HDL. You can go one step further and implement "stacked" memory
>> yourself, but then you have to write the muxing yourself, which
>> altsyncram does implicitly with MAXIMUM_DEPTH.
>>
>> -- Pete
>
> If you need asynchronous operation (2 clocks) you could mix both
> methods
> using a synchronous (single clock) FIFO after the async one.  Of course
> cascading FIFO's will increase the latency.
>

Hi Pete and Gabor,

I'm not HDL savvy enough myself, but I could handle the code if its 
available :)
My application can stand a little latency if cascading fifo's is easy.
Is this cascading easy or are there examples on the net somewhere?

One other thing is that I don't need a free solution.

Thanks,
Ken 



Article: 79316
Subject: Re: PPC405 sleep?
From: "Bo" <bo@cephus.com>
Date: Thu, 17 Feb 2005 07:41:08 -0600
Links: << >>  << T >>  << A >>
Michael,

Thanks for taking a look. I changed the ext int ISR in vxWorks to always set 
the PIT enable and PIT auto-reload bits (in case the execution of ISR was 
the first execution after being put to sleep) and got the exact same 
results. Any ideas?

You were right that the LED toggler did show up in the "i" command 
response--under a different name-and as 'READY'--however it was not 
executing. (???)

Thanks again...

Paul


"Michael Lawnick" <m.lawnick@kontron-applications.de> wrote in message 
news:4214442d_2@news.arcor-ip.de...
> Bo said the following:
>> I am trying to put the PPC405 asleep on a VirtexIIPro ML310 Xilinx
>> development board and not have a lot of luck. I'm running VxWorks and 
>> have
>> written a little application that toggles an LED so that I know the task 
>> is
>> running. I've tried two methods--with drastically different results-- but
>> neither of which do everything I need.
>>
>> First try:
>>
>>  I loaded my app that toggles LEDs via a Tornado shell.
>>
>> Spawn the LED toggler.
>>
>> Note that via Tornado shell, I see LED toggler in the task list at an "i"
>> command. Note that via the serial shell, I cannot see LED toggler in the
>> task list at an "i" command.
> Well, I'd expect you see it, but not with the expected symbolic name. As
> you loaded the code via host shell, you'd need to include host sym table
> sync to your target's image.
>
>>
>> Disable PIT, so only a UART or network source interrupt will awaken me 
>> (ie
>> no sysClk/timer interrupts)
>>
>> Put to sleep via  MSR[WE].  Observed LED quits toggle-- as expected.
>>
>> Then, via a SERIAL shell, I type "i", and vxWorks awoke and printed the
>> tasks data as expected-but the LED toggler did not resume execution.
>>
> How should it?
> You disabled timer interrupt!
>
>> Second try:
>>
>> I moved all this code into UsrAppInit and then programmatically, spawned 
>> the
>> LED toggler. Wait a few secs (so I can observe LED on scope). Then 
>> Disable
>> PIT and put to sleep.
>>
>> Now, I try to awaken the PPC405 via the serial connection. I cannot seem 
>> to
>> waken the PPC at all. If/when it wakens, the next line of code in 
>> usrAppInit
>> would have printed out an "Awoken" message--but I never see this happen.
>>
>> Note that the Msr register is set to 0x00069200 to initiate the 
>> sleep-which
>> should set the sleep bits, and enable critical and external interrupts
>> (though the PIT as a possible feeder to External Interrupt has been 
>> disabled
>> via a write to TCR of 0x00040000...)
>>
>> Someone else had mentioned to me the need for possible sync and orderly
>> execution before putting the PPC to sleep, so I added "sync, isync, and
>> eieio" code immediately prior to the set MSR[WE] bit, but this made no
>> difference. Any ideas?
>>
> First action in your UART's ISR should be to re-enable timer interrupt.
> This is a major device, VxWorks can't run without it properly.
>
> HTH
>
> -- 
> Regards,
> Mit freundlichen Grüßen,
> Michael Lawnick
>
> HTML-Mail is the first choice to distribute EMail-worms and -virii.
> Back to the roots! 




Article: 79317
Subject: Re: Any Altera FIFO not a power of 2?
From: "Gabor" <gabor@alacron.com>
Date: 17 Feb 2005 05:45:56 -0800
Links: << >>  << T >>  << A >>

Kenneth Land wrote:
> "Gabor" <gabor@alacron.com> wrote in message
> news:1108496252.756870.206390@l41g2000cwc.googlegroups.com...
> >
> > Peter Sommerfeld wrote:
> >> Hi Ken,
> >>
> >> I've done this before by writing my own fifo using the altsyncram
> >> megafunction. altsyncram has a parameter MAXIMUM_DEPTH which
allows
> >> non-power-of-2 depths. Adding single-clock FIFO functionality
(read
> > and
> >> write ptr management at a minimum) shouldn't be more than 20 lines
of
> >> HDL. You can go one step further and implement "stacked" memory
> >> yourself, but then you have to write the muxing yourself, which
> >> altsyncram does implicitly with MAXIMUM_DEPTH.
> >>
> >> -- Pete
> >
> > If you need asynchronous operation (2 clocks) you could mix both
> > methods
> > using a synchronous (single clock) FIFO after the async one.  Of
course
> > cascading FIFO's will increase the latency.
> >
>
> Hi Pete and Gabor,
>
> I'm not HDL savvy enough myself, but I could handle the code if its
> available :)
> My application can stand a little latency if cascading fifo's is
easy.
> Is this cascading easy or are there examples on the net somewhere?
>
Cascading is fairly simple.  The only thing you do extra is control
data flowing between FIFO's.  The first FIFO would be read whenever the
second FIFO is not full and not almost full (full - 1).  The almost
full is required to prevent data read on one clock from writing
a full FIFO on the next.  Then the second FIFO is written when new data
is read from the first.  I haven't used Altera FIFO's but usually this
is
one clock cycle after reading a non-empty first fifo.

If you have independent read and write clocks, the first FIFO could be
single-clock using the write clock for the second FIFO.  Alternately
you could make the first FIFO dual-clocked and the second FIFO single-
clocked using the read clock from the first FIFO.  The second approach
may be easier for the almost-full flag implementation, since it is
easier to produce flags in a single-clock design.

With Xilinx designs I use the COREgen FIFO's and this approach works
either way.

> One other thing is that I don't need a free solution.
> 
> Thanks,
> Ken


Article: 79318
Subject: Re: PPC405 sleep?
From: Michael Lawnick <m.lawnick@kontron-applications.de>
Date: Thu, 17 Feb 2005 14:56:00 +0100
Links: << >>  << T >>  << A >>
Bo said the following:
> Michael,
> 
> Thanks for taking a look. I changed the ext int ISR in vxWorks to always set 
> the PIT enable and PIT auto-reload bits (in case the execution of ISR was 
> the first execution after being put to sleep) and got the exact same 
> results. Any ideas?
> 
> You were right that the LED toggler did show up in the "i" command 
> response--under a different name-and as 'READY'--however it was not 
> executing. (???)
> 
For both problems:
make _sure_ that your PIT is getting reenabled on UART-int.
You could do it by attaching an ISR that toggles the LED ;-)
As long as PIT doesn't work properly, scheduling of tasks that are on
taskDelay() won't work anymore. Other tasks pending on semaphores will
work nevertheless.

-- 
Regards,
Mit freundlichen Grüßen,
Michael Lawnick

HTML-Mail is the first choice to distribute EMail-worms and -virii.
Back to the roots!

Article: 79319
Subject: Re: Questions about multiple rom instances in Quartus II
From: "Vaughn Betz" <no_spam@altera.com>
Date: Thu, 17 Feb 2005 09:12:01 -0500
Links: << >>  << T >>  << A >>
Hi John,

In case you don't have the code all sorted yet, here's a tutorial on how to 
change the megawizard generated module to pass down the hex file parameter 
you need (thanks to one of our megafunction gurus):

You need to parameterize the wizard generated blackbox module.
By default, the wizard generated module is fully customized according to the 
user selection in the wizard.

If you need to instantiate multiple instances which are variations of a base 
module, you can parameterize the variation in the base module.

For example, the following would be a typical wizard generated ROM module.

module myrom (

            address,

            clock,

            q);



            input     [4:0]  address;

            input       clock;

            output   [7:0]  q;



            wire [7:0] sub_wire0;

            wire [7:0] q = sub_wire0[7:0];



            altsyncram        altsyncram_component (

                                                .clock0 (clock),

                                                 ...

                                                 ...

                                                 .q_a(sub_wire0));



            defparam

                        altsyncram_component.operation_mode = "ROM",

                        ....

                        ....

                        altsyncram_component.init_file = "test.mif",

                        ....







You can parameterize the above module by changing it to the following (I 
highlighted the change in red)



module myrom (

            address,

            clock,

            q);



            input     [4:0]  address;

            input       clock;

            output   [7:0]  q;



            parameter mif_file = "test.mif";



            wire [7:0] sub_wire0;

            wire [7:0] q = sub_wire0[7:0];



            altsyncram        altsyncram_component (

                                                .clock0 (clock),

                                                 ...

                                                 ...

                                                 .q_a(sub_wire0));



            defparam

                        altsyncram_component.operation_mode = "ROM",

                        ....

                        ....

                        altsyncram_component.init_file = mif_file,

                        ....







And now they can instantiate the instance with different mif_file on the 
upper level source.

"John Rible" <jrible@sandpipers.com> wrote in message 
news:cuuoep0fmo@enews4.newsguy.com...
>
> Subroto Datta wrote:
>> Hi John,
>>
>> You will need to expose the parameter that is used for the .hex 
>> initialization file.  The MegaWizard-generated Verilog file will have a 
>> line saying defparam <instname>.INIT_FILE = "foo.hex"; that parameter 
>> needs to be added to the MegaWizard-generated module and passed down. 
>> Then assign a unique value for that parameter to each instantiation of 
>> the wizard-generated ROM sub-module.
>
> I've already tried using defparam (without adding it to the top file) and 
> got:
> Error: Verilog HDL or VHDL error at c18m.v(78): Unconverted VERI-2009: no 
> support for cross-hierarchy defparam id 
> c.RS.m.altsyncram_component.init_file
>
> Tomorrow I'll 'expose' the parameter. Also, Verilog 1995 didn't support 
> string parameters; is that the problem?
>
>> As for the question on inversions: all our blocks have programmable 
>> inversions on the inputs, so we allow inverts to be absorbed across 
>> hierarchy boundaries. The solution would be to insert an LCELL buffer to 
>> prevent the programmable inversion being propagated.
>>
>>
>>
>> Where the code has
>>
>>
>>
>> wire inverted_signal;
>>
>>
>>
>> You will need to add
>>
>> wire buffered_inverted_signal;
>>
>> lcell lcell_inst (inverted_signal, buffered_inverted_signal);
>>
>>
>>
>> and this will prevent the inversion propagating. However, It will use up 
>> an LE.
>
> Thanks a lot!
>
> -John
>
>> Hope this helps,
>>
>> Subroto Datta
>>
>> Altera Corp. 



Article: 79320
Subject: Re: 2 microblaze access same BRAM ?
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Thu, 17 Feb 2005 15:19:07 +0100
Links: << >>  << T >>  << A >>
Since both processors starts at address 0, they will start to execute the same 
initialization code.
You need to use a FSL port with different constant signals for each MicroBlaze.
The boot code would then read the FSL port to know which MicroBlaze it's.
Using this it would jump to the right code section.

I would have all code tied on one processor and letting the other processor 
using this as in will start to execute the same program.

Our JTAG debug module handles concurrently up to 8 MicroBlazes in parallel so 
there is no problem debugging this. You will get a gdb window for each MicroBlaze.

It can all be done in the current tools, so just start and have some fun.

Göran

Elinore wrote:
> hi
> 
> Final --: questions are about the suggestions above- multi-programming
> and FSL.
> I find FSL is a point2point link in the product specification.
> It seems that two approaches are totally different.
> Does EDK support such a multi-programming? If yes, in which way? How
> can we emulate the shared memory hardware and software (for example,
> threaded programming) in Xilinx tool?
> 
> 2 microblazes with FSL and shared memory ; this looks very exotic and
> it seems that we still have two independent main() routines.
> In any case, it will be interesting that one main() routine
> transperently describe  an algorithm and two microblazes coorperate
> each other.
> 
> By the way, thankyou very much, Göran
> 

Article: 79321
Subject: Re: Announcing Samplify for Windows: high-speed sampled data compression
From: "samplify" <awegener@samplify.com>
Date: 17 Feb 2005 06:20:22 -0800
Links: << >>  << T >>  << A >>
Thanks for Norm's request for clarification about the form in which
Samplify's sampled data compression is available.

While Samplify Systems is targeting the high-speed data acquisition and
signal processing markets that usually use DSP chips (from TI,
Freescale, Analog Devices, etc.) and FPGAs (from Xilinx and Altera), we
are happy to discuss other embedded target environments in which C
source code might be required.

Samplify is a low-MIPS algorithm that runs at 10+ Msamp/sec compression
and decompression rate using a 2 GHz Pentium.  If your sampling rate
requirements are at lower sampling rates (lower than 2 Msamp/sec, for
example),  or if you have non-realtime (offline) compression
requirements, please contact Samplify Systems at info@samplify.com to
discuss a port of Samplify compression to your particular target
environment.

Thanks,
Al

Norm Dresner wrote:
>
> Since you've chosen to post this message in comp.arch.embedded, you
are
> obviously aware that most of us here don't use Windows [in fact most
of the
> readers of this NG don't even use Intel x86 architecture CPUs] -- you
are
> aware of it, aren't you???
>
> Anyway, since you've chosen to advertise this in a newsgroup
dedicated to a
> very large variety of CPU architectures and operating systems, I'd
like to
> know when you'll have a generic version (preferably source code)
available ?
> 
>     Norm


Article: 79322
Subject: Re: Updated Stratix II Power Specs & Explanation
From: "Vaughn Betz" <no_spam@altera.com>
Date: Thu, 17 Feb 2005 09:33:30 -0500
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin@xilinx.com> wrote in message 
news:cuvptt$baj6@cliff.xsj.xilinx.com...
> Vaugn,
>
> Shell and pea game:  no, you do not get the entire benefit of reduced C.

The entire benefit would be 19% speed and dynamic power reduction.  As I 
said, we get about 2/3 of that maximum benefit, since not all C is metal C, 
but most is.
>
> Also, not all layer dielectrics are Lo-K.  For example, the clock tree is 
> near the top, where regular dielectric is used, isn't it?

We use low-k to near the top of the metal stack.  At the very top, where 
you're routing power and ground, you don't need (or even want it), since 
high capacitance on power and ground is beneficial (helps prevent ground 
bounce & vcc sag).  The vast majority of the switching capacitance (clocks, 
routing, ALMs, MACs, etc.) is in metal surrounded by low-k.

> At least, we evaluated both with, and without Lo-K devices (from the same 
> masks and fab), and were surprised to see only a 5% improvement.
>
> Did you do the same experiment?  We were surprised.

We simulated everything with and without low-K, and got the ~13% improvement 
I previously mentioned.  I am also surprised you got only 5%.  That is 
certainly well below mainstream for the industry -- if everyone were seeing 
such small gains, I doubt the fabs and semiconductor equipment vendors would 
be pumping billions into developing low-k (and next generation extra-low-k) 
dielectrics.  Sounds like you may have used low-k for only a few metal 
layers, so perhaps that explains your disappointing experience.

> Turns out, there is a lot more in the equations that just C.
>
> If it was just that simple, extracted simulations in spice would be 
> unneeded.

This is backwards.  As metal capacitance has become the dominant 
capacitance, extracting layouts to obtain all the metal parasitics before 
running SPICE has become essential to getting accurate answers.  Go back 
enough process generations and this was less true -- you could write up your 
transistor-level schematic in a SPICE deck, simulate it with no thought of 
metal, and you wouldn't be that far off for most circuits, since transistor 
parasitics dominated.  Now that metal dominates, you have to extract layouts 
to get the metal C or you get bad answers.

Vaughn Betz
Altera
[v b e t z (at) altera.com]



Article: 79323
Subject: Re: clock split approach for 270MHz design in Spartan2E
From: "AugustoEinsfeldt" <aee@terra.com.br>
Date: 17 Feb 2005 06:35:53 -0800
Links: << >>  << T >>  << A >>
Thanks for the replys. This application is cost sensitive and SP3 is
the best choice for production but when the this design was made the
SP3 was not easily available and customer is reluctant to use BGA
packages (also because PCB costs).
This statement in XAPP250's summary: "..With minor modifications,
Clock and Data Recovery (CDR) is possible with Virtex-E and
Spartan=99-IIE devices..." and since XC2S200E-6 is under this limits (I
know it is barely bellow maximum) made me believe I could do it with
this device I had in hands.
If you believe I cannot do it I wont waste time trying and will ask
customer to make a new PCB using SP3.


Article: 79324
Subject: Re: PLB
From: Nju Njoroge <njoroge@stanford.edu>
Date: Thu, 17 Feb 2005 06:50:21 -0800
Links: << >>  << T >>  << A >>
Hi,

I had designed a simple PLB master and posted some questions on the news
group. The thread message was titled "Designing a simple PLB Master using
EDK 6.3i". The last message in the thread was 2/1/2005. Read it is to see
if it helps in general (refer to the PLB PDF document that I referenced in
the thread).

Addressing your specific question, I have never dealt with the problem you
are dealing with. Is the slave asking you to "retry" the request again?

All the best,

NN
 On 16 Feb 2005 mmkumar@gmail.com wrote:

> Hi,
>   I am desging an master interface for 64-bit PLB.when i am not locking
> the bus and if i get a Mn_rearbitrate from the slave ,and am
> de-asserting and asserting the request after one clk.But it seems like
> the arbiter is not arbitrating the request from the me(master) after it
> got an M1_rearbitrate(never i get the bus , after that), how i can i
> proceed further to do my data transfer.
>
> thanx,
> mack.
>
>






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