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 106925

Article: 106925
Subject: PCIe latency
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Tue, 22 Aug 2006 17:24:35 +0000 (UTC)
Links: << >>  << T >>  << A >>

Hello,

Suppose I have a PCIe core in an FPGA on a PCIe card plugged into a modern
PC.  What read latency should I expect?  How much time is it from when I
submit a request to the PCIe core to read from the PC's main memory to when
I get back the first datum from the PCIe core?  How does this compare to
PCI-X?

We're architecting a new system and trying to get typical FPGA-based PCIe
latency values.

Also, we're looking for recommendations for an 8-lane PCIe development/eval
card.  Which cards are people using?

Thanks
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 106926
Subject: Re: OFFSET with DCM NET or derived NET?
From: "Brandon Jasionowski" <killerhertz@gmail.com>
Date: 22 Aug 2006 10:25:32 -0700
Links: << >>  << T >>  << A >>
So, if I have an internally generated clock from a DCM's fx output,
"CLK_FX" feeding a group of registers, which are driving pins,
"DATA_OUT<*>" what would you recommend?

TIMESPEC "TS_DATA_OUT" FROM "CLK_FX" TO "DATA_OUT" 5 ns; # how about
this?

Thanks,
-Brandon

Gabor wrote:
> Brandon Jasionowski wrote:
> > I have been trying to use an internal clock net in my offset
> > constraint, sourced from a DCM instance. This appears to be legal,
> > according to the CGD: "OFFSET is used only for padrelated
> > signals, and cannot be used to extend the arrival time specification
> > method to the
> > internal signals in a design. A clock that comes from an internal
> > signal is one generated
> > from a synch element, like a FF. A clock that comes from a PAD and goes
> > through a DLL,
> > DCM, clock buffer, or combinatorial logic is supported."
> >
> > But, this doesn't work for me. If I use the original clock pad in the
> > constraint it works. However, these OFFSETS are driven by a DCM FX
> > output, so the timing is different from the original. Will ISE infer
> > this timing difference? It appears to be unclear to me...
> >
> > Thanks,
> > -Brandon
>
> Normally ISE will infer the timing difference correctly if there is a
> simple relationship (like 1:1) from the external pad frequency to
> the internal FX clock frequency.  Since the OFFSET is used for
> PAD signals, this would make sense, since there would have to
> be an assumed phase relationship between the external pad signal
> requiring the OFFSET constraint and the internal clock.  If the
> signals requiring the OFFSET constraint are not externally
> generated, it would normally make sense to use a PERIOD or
> FROM : TO constraint instead.
> 
> HTH,
> Gabor


Article: 106927
Subject: Xilinx FPGA editor error ISE8.2
From: yttrium <yttrium@telenet.be>
Date: Tue, 22 Aug 2006 20:16:19 +0200
Links: << >>  << T >>  << A >>
Hey, when i run a script through FPGA editor i get the following error:

setattr comp 
c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2) 
Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\ 
IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\ 
IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4
ERROR:FPGAEditor:25 - "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK 
IDELAYMUX:1 IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 
INIT_Q4:0 IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4" 
is not a valid value for the Config attribute.  BRBCF ILOGIC Failure: 
INVALID_RB: "IFF1::\#FF" CFG: "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK 
IDELAYMUX:1 IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 
INIT_Q4:0 IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4"

even when i make this change manually and then save and record this a 
script and then run it, it gives me that error. So when FPGA editor 
generates the following statement:

setattr comp 
c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2) 
Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\ 
IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\ 
IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4

and that one is exactly the same as the one in my script then what am i 
doing wrong??? to get me that answer?

Thanks in advance for your help,

kind regards,

Tim

Article: 106928
Subject: Re: OFFSET with DCM NET or derived NET?
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 22 Aug 2006 18:25:32 GMT
Links: << >>  << T >>  << A >>
Use the original clock in your spec; the tools should infer the derived 
clock properly.  I've seen the tool work properly when switching to or from 
the CLKFX domain internall, I'd be surprised if it didn't do a proper job 
externally.


"Brandon Jasionowski" <killerhertz@gmail.com> wrote in message 
news:1156256235.404717.265480@i42g2000cwa.googlegroups.com...
>I have been trying to use an internal clock net in my offset
> constraint, sourced from a DCM instance. This appears to be legal,
> according to the CGD: "OFFSET is used only for padrelated
> signals, and cannot be used to extend the arrival time specification
> method to the
> internal signals in a design. A clock that comes from an internal
> signal is one generated
> from a synch element, like a FF. A clock that comes from a PAD and goes
> through a DLL,
> DCM, clock buffer, or combinatorial logic is supported."
>
> But, this doesn't work for me. If I use the original clock pad in the
> constraint it works. However, these OFFSETS are driven by a DCM FX
> output, so the timing is different from the original. Will ISE infer
> this timing difference? It appears to be unclear to me...
>
> Thanks,
> -Brandon
> 



Article: 106929
Subject: Re: Xilinx FPGA editor error ISE8.2
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 22 Aug 2006 18:37:30 GMT
Links: << >>  << T >>  << A >>
I don't have an answer, but a suggestion:  break the config into its parts. 
If you set the Config IFF1 in one line and Config INIT_Q4 in another - just 
one per line - you might find out what "really" fails.

If I had to guess I'd think the line length in your command is a problem. 
Breaking it up eliminates this issue and can let you debug the problem to 
its core.


"yttrium" <yttrium@telenet.be> wrote in message 
news:%RHGg.127097$YS7.119815@blueberry.telenet-ops.be...
> Hey, when i run a script through FPGA editor i get the following error:
>
> setattr comp 
> c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2) 
> Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\ 
> IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\ 
> IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4
> ERROR:FPGAEditor:25 - "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK IDELAYMUX:1 
> IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 INIT_Q4:0 
> IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4" is not a 
> valid value for the Config attribute.  BRBCF ILOGIC Failure: INVALID_RB: 
> "IFF1::\#FF" CFG: "CE1INV:CE1 CLKDIVINV:CLKDIV CLKINV:CLK IDELAYMUX:1 
> IFF1:\#FF IFFDELMUX:0 IFFMUX:1 INIT_Q1:0 INIT_Q2:0 INIT_Q3:0 INIT_Q4:0 
> IOBDELAY_TYPE:VARIABLE IOBDELAY_VALUE:0 Q1MUX:IFF3 Q2MUX:IFF4"
>
> even when i make this change manually and then save and record this a 
> script and then run it, it gives me that error. So when FPGA editor 
> generates the following statement:
>
> setattr comp 
> c_DDR2_framebuffer_0/c_Ddr2Interface/i_DDR/i_DdrInputOutput_DataEvenFromSdr_d(2) 
> Config CE1INV:CE1\ CLKDIVINV:CLKDIV\ CLKINV:CLK\ IDELAYMUX:1\ IFF1:\#FF\ 
> IFFDELMUX:0\ IFFMUX:1\ INIT_Q1:0\ INIT_Q2:0\ INIT_Q3:0\ INIT_Q4:0\ 
> IOBDELAY_TYPE:VARIABLE\ IOBDELAY_VALUE:0\ Q1MUX:IFF3\ Q2MUX:IFF4
>
> and that one is exactly the same as the one in my script then what am i 
> doing wrong??? to get me that answer?
>
> Thanks in advance for your help,
>
> kind regards,
>
> Tim 



Article: 106930
Subject: Xilinx Virtual Platform
From: Sylvain Munaut <tnt-at-246tNt-dot-com@youknowwhattodo.com>
Date: Tue, 22 Aug 2006 21:04:08 +0200
Links: << >>  << T >>  << A >>
Hi everyone.

I was just wondering if someone knew where to find documentation about
the Xilinx Virtual Platform.

I'm interested in writing simulation models for my own cores. Since
those cores have external interface, they can't be autogenerated and
they're critical to my application ... (the code will do nothing
without them).

Currently, I've managed by a few hacks to do pretty much what I
want but I'd like to know if there is any documentation about it ?
Because I didn't find much ;(



    Sylvain

Article: 106931
Subject: Re: Xilinx Virtual Platform
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 22 Aug 2006 21:24:20 +0200
Links: << >>  << T >>  << A >>
"Sylvain Munaut" <tnt-at-246tNt-dot-com@youknowwhattodo.com> schrieb im 
Newsbeitrag news:44eb5529$0$32429$ba620e4c@news.skynet.be...
> Hi everyone.
>
> I was just wondering if someone knew where to find documentation about
> the Xilinx Virtual Platform.
>
> I'm interested in writing simulation models for my own cores. Since
> those cores have external interface, they can't be autogenerated and
> they're critical to my application ... (the code will do nothing
> without them).
>
> Currently, I've managed by a few hacks to do pretty much what I
> want but I'd like to know if there is any documentation about it ?
> Because I didn't find much ;(
>
>    Sylvain

no there isnt - thats the reason I working on XSIM the only simulator up 
today that succesfully runs MicroBlaze uClinux unmofied images

is pretty fun to see peripherals like

sd card
systemace
ide disk
i2c rtc
video display
pictiva oled

to work from the microblaze simulator :)

the plugin API for the XSIM simulator is also available. fully documentated 
!

Antti
PS EDK 811 VP sim does choke on uclinux images ASFAIK



Article: 106932
Subject: Re: CPU design
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 23 Aug 2006 07:42:53 +1200
Links: << >>  << T >>  << A >>
radarman wrote:
>>>Maybe you are right and the core and programs are smaller with Forth, I'll
>>>think about it. Really useful is that it is simple to write an interactive
>>>read-eval-print loop in Forth (like in Lisp), so that you can program and
>>>debug a system over RS232.
>>>
> 
> 
> Simpler solution - have the microcode FSM push the flags to the stack.
> It's a simple alteration, and saves a lot of heartache. I have
> contemplated even pushing the entire context to the stack, since I can
> burst write from the FSM a lot faster than I can with individual
> PSH/POP instructions, but I figure that would be overkill.

For someone doing a fully custom/own assembler/compiler :

The tiniest CPUs do not need a stack, and interupts do not need to be
re-entrant, so a faster context switch is to re-map the Registers, Flags 
(and even PC ? ) onto a different area in BRAM.
You can share this resource by INTs re-map top-down, and calls re-map
bottom up - with a hardware trap when they collide :)

-jg


Article: 106933
Subject: Re: Xilinx Virtual Platform
From: Sylvain Munaut <tnt-at-246tNt-dot-com@youknowwhattodo.com>
Date: Tue, 22 Aug 2006 21:43:15 +0200
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> "Sylvain Munaut" <tnt-at-246tNt-dot-com@youknowwhattodo.com> schrieb im 
> Newsbeitrag news:44eb5529$0$32429$ba620e4c@news.skynet.be...
>> Hi everyone.
>>
>> I was just wondering if someone knew where to find documentation about
>> the Xilinx Virtual Platform.
>>
>> I'm interested in writing simulation models for my own cores. Since
>> those cores have external interface, they can't be autogenerated and
>> they're critical to my application ... (the code will do nothing
>> without them).
>>
>> Currently, I've managed by a few hacks to do pretty much what I
>> want but I'd like to know if there is any documentation about it ?
>> Because I didn't find much ;(
>>
>>    Sylvain
> 
> no there isnt - thats the reason I working on XSIM the only simulator up 
> today that succesfully runs MicroBlaze uClinux unmofied images

Well, I got it to run ... but I thought there might be a doc to be sure
I was doing it right.

I saw xsim

> is pretty fun to see peripherals like
> 
> sd card
> systemace
> ide disk
> i2c rtc
> video display
> pictiva oled
> 
> to work from the microblaze simulator :)
> 
> the plugin API for the XSIM simulator is also available. fully documentated 
> !

Well, I tried to find the link again on xilant.com but I just couldn't ...

And the last time I saw it, it was windows only and I'm a linux guy ...
A shame though because a nice simulator would definitly be useful


    Sylvain

Article: 106934
Subject: Re: CPU design
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 23 Aug 2006 08:06:16 +1200
Links: << >>  << T >>  << A >>
Göran Bilski wrote:
> 
> Things to keep in mind is to handle larger arithmetic than 16 bits.
> That will usually introduce some kind of carry bits (stored where?).
> You seems to have a c,z bits somewhere but you will need two versions of 
> each instruction, one which uses the carry and one which doesn't
> 
> Running more than just simple programs in real-time applications 
> requires interrupt support which messes things up considerable in the 
> control part of the processor.
> 
> Do you consider using only absolute branching or also doing relative 
> branching?
> 
> If you really are wanting to have a processor which is code efficient, 
> you might want to look at a stack machine.
> If I was to create a tiny tiny processor with little area and code 
> efficient I would do a stack machine.
> But they are much nastier to program but they can be implemented very 
> efficiently.

One stack machine, that is still small, but could help greatly with
software flows (being an already defined std)
is the Instruction List language of IEC 61131-1

http://www.3s-software.com/index.shtml?CoDeSys_IL

and

http://en.wikipedia.org/wiki/Instruction_list

in a 'full' system, this supports many data type sizes, but you could
nominate a single size for this task.

IEC Conventions:
Prefix      Meaning
%           variable
  I			Input Location
  Q			Output Location
  M			Memory Location
    	(none)	Single Bit default
   X			Single Bit
   B			Byte   ( 8 bits )
   W			Word   ( 16 bits )
   D			Double ( 32 bits )
   L			Long   ( 64 bits )
   N			Nibble ( 4 bits )


Opcode encoding is quite small, and you can see some commonality with
PicoBlaze and Mico8 cores.

You do need to define a memroy-reach limit quite early on any CPU design.

-jg


Article: 106935
Subject: hex and AHDL?
From: "jacko" <jackokring@gmail.com>
Date: 22 Aug 2006 14:35:31 -0700
Links: << >>  << T >>  << A >>

Ralf Hildebrandt wrote:

> jacko wrote:
> > in quartus II loading a .hex file into 16 bit rom, would it be little
> > endian, or is only low byte filled??
>
> I can only speak for MaxPlus+ but there reading Intel hex is non-standard.
>
> Intel hex has always addresses pointing to 8 bit locations, while the
> destination width in MaxPlus changes. (16 bit destinations for 16 bit
> wide RAM)
>
> Intel hex is little endian, while Maxplus reads data in big endian order.
>
cheers, just wondered, as i like to consider full project task before
deciding exact implement.

may even use AHDL as its shorter and more sucinct, how custom vlsi is
the AHDL?

looks good for a verification platform, but must have lang export to
CIF and GDSII as eventual goals.

hope to get register unit done first

http://indi.joox.net

cheers jacko


Article: 106936
Subject: Re: Xilinx Virtual Platform
From: "jacko" <jackokring@gmail.com>
Date: 22 Aug 2006 14:38:01 -0700
Links: << >>  << T >>  << A >>

Sylvain Munaut wrote:

> Antti Lukats wrote:
> > "Sylvain Munaut" <tnt-at-246tNt-dot-com@youknowwhattodo.com> schrieb im
> > Newsbeitrag news:44eb5529$0$32429$ba620e4c@news.skynet.be...
> >> Hi everyone.
> >>
> >> I was just wondering if someone knew where to find documentation about
> >> the Xilinx Virtual Platform.
> >>
> >> I'm interested in writing simulation models for my own cores. Since
> >> those cores have external interface, they can't be autogenerated and
> >> they're critical to my application ... (the code will do nothing
> >> without them).
> >>
> >> Currently, I've managed by a few hacks to do pretty much what I
> >> want but I'd like to know if there is any documentation about it ?
> >> Because I didn't find much ;(
> >>
> >>    Sylvain
> >
> > no there isnt - thats the reason I working on XSIM the only simulator up
> > today that succesfully runs MicroBlaze uClinux unmofied images
>
> Well, I got it to run ... but I thought there might be a doc to be sure
> I was doing it right.
>
> I saw xsim
>
> > is pretty fun to see peripherals like
> >
> > sd card
> > systemace
> > ide disk
> > i2c rtc
> > video display
> > pictiva oled
> >
> > to work from the microblaze simulator :)
> >
> > the plugin API for the XSIM simulator is also available. fully documentated
> > !
>
> Well, I tried to find the link again on xilant.com but I just couldn't ...
>
> And the last time I saw it, it was windows only and I'm a linux guy ...
> A shame though because a nice simulator would definitly be useful
>
got altera stuff as xilinx seems to send multiple emails welcoming me
to the ISE, but never gives up the program.

cheers


Article: 106937
Subject: Re: Configuring an Altera Serial Prom/Flash using a 8051 CPU
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Tue, 22 Aug 2006 23:54:57 +0200
Links: << >>  << T >>  << A >>
Hi handyman,

> Has anyone experience with prgramming a serial prom/flash like the EPCS16
> using a 8051 compatible uP.
> It looks like srunner C code from Altera has some some useable rutines but
> a 8051 device driver and file driver is needed.

The file driver is only needed to get the raw binary bytes in on a PC - if
running on an 8051 you could just take data from a UART or I2C.

The 8051 device driver needs to be hand-rolled - it completely depends on
which port pins SDI, SDO, SCK and CS are mapped. The PC version uses the
parallel port to do its stuff. This bit should take less than one day to
write and debug; the file-I/O completely depends on how you want to feed
the actual configuration data to the 8051.

Best regards,


Ben


Article: 106938
Subject: Re: Xilinx .002ns timing error
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 22 Aug 2006 14:59:31 -0700
Links: << >>  << T >>  << A >>
> I usually choose to specify it in ps, trying to get a number that leads
> to an integer number of ps for the FX period.
> For example, if you had 133 MHz as a constraint, use 7497 ps as a
> period ...  7497 / 7 * 2 = 2140 ps ...


That did it! Thank you, Sylvain.

#TIMESPEC "TSCAM2" = PERIOD "cam2_xclk" 40MHz HIGH 50 %;  -- errors
TIMESPEC "TSCAM2" = PERIOD "cam2_xclk" 24997ps HIGH 50 %;

Brad Smallridge
aivision 



Article: 106939
Subject: ISE 8.2i and EDK 8.1i
From: polkid@gmail.com
Date: 22 Aug 2006 15:01:01 -0700
Links: << >>  << T >>  << A >>
Okay here's my problem,

My company got a dev board from Avnet with a Xilinx Virtex 4 FX12 FPGA
on it.

So Xilinx sends us ISE 8.2i to use per our lisense.

Avnet sends us EDK 8.1i to use.

They won't work together! I get an error everytime I try to start up
either XPS or EDK. Avnet says they sent me the most up to date version
of the software that they have, and to download EDK 8.2i from the
Xilinx website, but I can't find anywhere on their website to acutally
download it!

Any suggestions?

Thanks!

Wade


Article: 106940
Subject: Re: CPU design
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 23 Aug 2006 00:06:28 +0200
Links: << >>  << T >>  << A >>
jacko wrote:

> search for MSL16 as a compact example of stack machine, i would use
> slightly different ops, and things if i did it.

The paper at 

http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/old/msl16/fccm98_fcpu.pdf

says it needs 175 CLBs on a Xlinx FPGA. And 

http://www.xilinx.com/publications/xcellonline/xcell_48/xc_picoblaze48.htm

says that the PicoBlaze needs 76 slices (311 slices, if you add serial
ports and timers). I'm not sure if this is valid for every FPGA, but
somewhere I've read that 4 slices = 1 CLB, so the MSL16 needs more than 9
times more logic gates than PicoBlaze. This is not my idea of a small core.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106941
Subject: Running DDR below the min frequency
From: rick@mips.com
Date: 22 Aug 2006 15:08:08 -0700
Links: << >>  << T >>  << A >>
This post might not be directly on topic here but I'm hoping that
someone else out in FPGA-land might have come across a similar problem.

The problem: I'm using an FPGA to do emulation of RTL that would
normally be build into an ASIC.As such, therefore, the RTL is not very
`FPGA friendly' and I can only get a speed of 33-40MHz, maybe 50 at a
push. The trouble is that the system incorporates a DDR DRAM controller
and DDR DRAMs have a min. frequency spec - 66MHz in the case of the
ones I'm using - related to the internal DLL. I *think* that this is
why I'm getting no response from the RAMs during read cycles & the data
bus seems to be floating.

I've tried running with both DLL enabled and disabled to no avail.
[Maybe some manufacturers work in this mode and others don't].

Any ideas ?


Article: 106942
Subject: Re: Running DDR below the min frequency
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 22 Aug 2006 15:12:42 -0700
Links: << >>  << T >>  << A >>
r...@mips.com wrote:
> This post might not be directly on topic here but I'm hoping that
> someone else out in FPGA-land might have come across a similar problem.
>
> The problem: I'm using an FPGA to do emulation of RTL that would
> normally be build into an ASIC.As such, therefore, the RTL is not very
> `FPGA friendly' and I can only get a speed of 33-40MHz, maybe 50 at a
> push. The trouble is that the system incorporates a DDR DRAM controller
> and DDR DRAMs have a min. frequency spec - 66MHz in the case of the
> ones I'm using - related to the internal DLL. I *think* that this is
> why I'm getting no response from the RAMs during read cycles & the data
> bus seems to be floating.
>
> I've tried running with both DLL enabled and disabled to no avail.
> [Maybe some manufacturers work in this mode and others don't].
>
> Any ideas ?

The spec minimum for DDR is 83.33MHz. I have managed to make some run
at 66MHz, but I don't think you'll get them to run lower.

You are correct that this is related to the internal DLLs in the DDR.

If you can't bump the speed, I can't see that you'll be able to make it
work

Cheers

PeteS


Article: 106943
Subject: New release of HDLmaker
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Tue, 22 Aug 2006 19:18:34 -0400
Links: << >>  << T >>  << A >>
I've put a new release of HDLmaker on the web, you can get it at

http://www.polybus.com/hdlmaker/users_guide/index.htm

This release adds preliminary support for Virtex5. It also adds some
features for use in generating Verilog leaf files. HDLmaker's primary
focus is on generating hierarchical Verilog now it can be used for the
leaf modules also.

HDLmaker is open source, it's licensed under a BSD style license.


Article: 106944
Subject: Re: Running DDR below the min frequency
From: rick@mips.com
Date: 22 Aug 2006 16:35:30 -0700
Links: << >>  << T >>  << A >>

PeteS wrote:

> r...@mips.com wrote:
> > This post might not be directly on topic here but I'm hoping that
> > someone else out in FPGA-land might have come across a similar problem.
> >
> > The problem: I'm using an FPGA to do emulation of RTL that would
> > normally be build into an ASIC.As such, therefore, the RTL is not very
> > `FPGA friendly' and I can only get a speed of 33-40MHz, maybe 50 at a
> > push. The trouble is that the system incorporates a DDR DRAM controller
> > and DDR DRAMs have a min. frequency spec - 66MHz in the case of the
> > ones I'm using - related to the internal DLL. I *think* that this is
> > why I'm getting no response from the RAMs during read cycles & the data
> > bus seems to be floating.
> >
> > I've tried running with both DLL enabled and disabled to no avail.
> > [Maybe some manufacturers work in this mode and others don't].
> >
> > Any ideas ?
>
> The spec minimum for DDR is 83.33MHz. I have managed to make some run
> at 66MHz, but I don't think you'll get them to run lower.
>
> You are correct that this is related to the internal DLLs in the DDR.
>
> If you can't bump the speed, I can't see that you'll be able to make it
> work

There are solutions to my problem but, trouble is, I don't really like
any of them much:

o Run the controller part of the system on a 2x clock. The downside is
that this would give overly optimistic performance results.

o Run the DRAM clock at 2x and do some sort of conversion between the
controller's output and the DRAM control/datapath signals ... Ugly, esp
the write path!

o Similar to the previous but use ordinary SDR RAMs at 2x to emulate
DDR at 1x.

Rick


Article: 106945
Subject: Re: Running DDR below the min frequency
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 22 Aug 2006 16:39:18 -0700
Links: << >>  << T >>  << A >>
rick@mips.com wrote:

> This post might not be directly on topic here but I'm hoping that
> someone else out in FPGA-land might have come across a similar problem.
> 
> The problem: I'm using an FPGA to do emulation of RTL that would
> normally be build into an ASIC.As such, therefore, the RTL is not very
> `FPGA friendly' and I can only get a speed of 33-40MHz, maybe 50 at a
> push. The trouble is that the system incorporates a DDR DRAM controller
> and DDR DRAMs have a min. frequency spec - 66MHz in the case of the
> ones I'm using - related to the internal DLL. I *think* that this is
> why I'm getting no response from the RAMs during read cycles & the data
> bus seems to be floating.
> 
> I've tried running with both DLL enabled and disabled to no avail.
> [Maybe some manufacturers work in this mode and others don't].
> 
> Any ideas ?
> 
It seems pretty on-topic to me!

I can't answer your question directly, but I can think of two things you 
can do:

1.  Add a second (third, 99th, whatever) FPGA to implement a DDR DRAM 
emulator.  If you don't want mere test patterns out of it you'll 
probably have to back it up with static RAM or something.  You'll have 
the drawback that you're not giving the FPGA the 'real thing', but 
you'll at least be able to check for gross logic errors and even some 
glitches.

2.  Modify the RTL to be more FPGA friendly, but in a way that allows 
you to verify top-level equivalence.  This is even more remote from the 
first choice, but it gives you the satisfaction of seeing your stuff 
actually run DDR DRAM at full speed.

I assume that "Get a faster FPGA" has already been explored to it's 
fullest extent...

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 106946
Subject: Re: Running DDR below the min frequency
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 23 Aug 2006 12:58:12 +1200
Links: << >>  << T >>  << A >>
rick@mips.com wrote:
> There are solutions to my problem but, trouble is, I don't really like
> any of them much:
> 
> o Run the controller part of the system on a 2x clock. The downside is
> that this would give overly optimistic performance results.
> 
> o Run the DRAM clock at 2x and do some sort of conversion between the
> controller's output and the DRAM control/datapath signals ... Ugly, esp
> the write path!
> 
> o Similar to the previous but use ordinary SDR RAMs at 2x to emulate
> DDR at 1x.

Is 2 as bad as you think ? - you are only trying to keep the DLLs happy, 
so a simple scheme that reads-twice, and writes-twice, would get the 
clock into the DRAM realm, but the data-rate matches the larger system ?

-jg


Article: 106947
Subject: Re: CPU design
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 23 Aug 2006 03:00:33 +0200
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> One stack machine, that is still small, but could help greatly with
> software flows (being an already defined std)
> is the Instruction List language of IEC 61131-1
> 
> http://www.3s-software.com/index.shtml?CoDeSys_IL
> 
> and
> 
> http://en.wikipedia.org/wiki/Instruction_list

This looks very interesting, because every command has only one operand,
which make developing the core really easy and leaves much space for
addressing modes etc. in an opcode, even with 8 bit opcodes.

I'll try to mix this with my last addressing modes. I don't need "call",
because this is only a jump, where the return address is stored somewhere
(I don't need recursion).

4 bits: instruction
lda: load accu
sta: store accu
or: accu = accu or argument
xor: "
and: "
add: "
sub: "
cmp: "
bcc: branch if carry clear
bcs: branch if carry set
bne: branch if zero set
beq: branch if zero clear
jmp: jump
inp: read from port or special register (pc, flags, i/o ports, timer etc.)
outp: write to port or special register

I don't need it, but the last possible instruction could be rti, return
from interrupt, which restores pc, accu and the flags, which are saved on
interrupt entry. With inp/outp the interrupt address and frequency could be
setup.

4 bits: address mode (pc relative, 16 bit argument, doesn't make much
sense, so all useful combinations fits in 4 bits)

immediate, 8 bit argument
immediate, 16 bit argument
immediate, no arguments, #0
immediate, no arguments, #1

8 bit transfer width:
address, 8 bit argument 
address, 16 bit argument
address, pc relative, 8 bit argument
address indirect, 8 bit argument
address indirect, 16 bit argument
address indirect, pc relative, 8 bit argument

16 bit transfer width:
address, 8 bit argument
address, 16 bit argument
address, pc relative, 8 bit argument
address indirect, 8 bit argument
address indirect, 16 bit argument
address indirect, pc relative, 8 bit argument

The "pc relative" address modes adds the argument to the pc to get the
value. This can be used for the branches and jumps for short jumps, but as
well for using some kind of local variables. Let's try the swap algorithm:

; swap 6 byte source and destination MACs
p1:	.dw 0
p2:	.dw 0
tmp:	.db 0
	lda #5
	sta p1    (pc relative)
	lda #11
	sta p2    (pc relative)
loop:	lda (p1)  (address indirect, pc relative)
	sta tmp   (address, pc relative)
	lda (p2)  (address indirect, pc relative)
	sta (p1)  (address indirect, pc relative)
	lda tmp   (address, pc relative)
	sta (p2)  (address indirect, pc relative)
	lda p2    (pc relative)
	sub #1    (one byte, because #1 needs no operand)
	sta p2    (pc relative)
	lda p1    (pc relative)
	sub #1    (one byte, because #1 needs no operand)
	sta p1    (pc relative)
	bcc loop  (pc relative)

37 bytes

This is not as good as my RISC idea (20 bytes), but the code is much better
to understand: you need not to think about it when reading and writing it.
But maybe this is only because some ages ago I've written some demos and
intros on C64 (6502), which uses a similiar instruction set :-)

Do you think the core for this design would be smaller than PicoBlaze or my
RISC idea?

BTW: There are some nice contructs possible for smaller code, like to use
some kind of zero-page, like implemented in the 6502, because the lda/sta
instructions could be used with 8 bit arguments addresses. But code size
and speed is not so important for me, a small core is more important, and
maybe easy to write assembler code, to avoid implementing a GCC backend for
my CPU.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 106948
Subject: Re: Video - DSP Eval board with Altera
From: "Joel Seely" <jseely@altera.com>
Date: 22 Aug 2006 18:18:31 -0700
Links: << >>  << T >>  << A >>
The Stratix II DSP kits are readily available.  These both contain 2x
12-bit, 125MHz A/D and 2x 14-bit 165MHz D/A.  The ordering codes for
these are:

DK-DSP-2S60N
Featuring the Stratix II 2S60 part with ~60KLEs, >2.5Mb RAM, 36 DSP
Blocks.

DK-DSP-2S180N
Featuring the Stratix II 2S60 part with ~180KLEs, >9.3Mb RAM, 96 DSP
Blocks.

Additionally the Cyclone II version with a 2C70 device on it will be
shipping shortly (boards are done - just finalizing documentation).
The ordering code for this is:
DK-DSP-2C70N

Regards

-Joel-

homoalteraiensis wrote:
> Is there anybody out having experiences with an evaluation board,
> containing an Altera FPGA like Cyclone or Stratix and doing Video
> processing with it?
>
> Can anybody recoomend a certain board with a good analog behaviour
> (high dynamic ADC) - possibly with a (hard) DSP?
> 
> Thanks in advance.


Article: 106949
Subject: Re: Newbie frustration
From: Daniel O'Connor <darius@dons.net.au>
Date: Wed, 23 Aug 2006 11:13:41 +0930
Links: << >>  << T >>  << A >>
KJ wrote:

> Daniel O'Connor wrote:
> Many times this symptom is a result of a timing violation.  Check that
> the setup time and the clock frequency as reported by the place and
> route timing report is being met by whatever simulation model you have
> driving the design.

Yup, the requirements at the basic level are fairly modest, and my timing
constraints are being met.

> Also, check the list of warnings that pop out of the synthesis to look
> for things that you shouldn't try to do in an FPGA.  If you find them,
> you'll probably need to get rid of them.  Things like...
> - Transparent latches
> - Generating your own internal clocks (can be done, but only with
> care).

I need to generate an internal clock :(
Any tips on how to do it properly?
Hmm actually I can rejig the design to use an enable which is probably the
right thing to do.

> - Other warnings that pop out should also be perused to make sure you
> understand why it is a warning and if this is a concern in your design.
>  As with software, many times a compile time warning is a run time (or
> in your case timing simulation) error.

I have had an odd one which does not appear affect the final result - I have
a right shifter with a lookup table in front (for compatibility reasons) so
I do..
module shifter(DIN, SHIFT, DOUT);
   output [15:0] DOUT;  // Data out

   input [31:0]  DIN;   // Data in
   input [3:0]   SHIFT; // Amount to shift by (sort of)

   reg [15:0]    DOUT;
   reg [31:0]    TMPOUT;
   reg [3:0]     SHIFTp;

   always @(DIN or SHIFT) begin
      case (SHIFT)
        4'd13: // 8192 integrations (not possible in the old SA)
          SHIFTp = 13;
        4'd14: // 16384 integrations (not possible in the old SA)
          SHIFTp = 14;
        4'd15: // 32768 integrations (not possible in the old SA)
          SHIFTp = 15;
        4'd12: // 0/1 integrations
          SHIFTp = 0;
        4'd11: // 2 integrations
          SHIFTp = 1;
[...]
      endcase // case(SHIFT)

      TMPOUT = DIN >> SHIFTp;
      DOUT = TMPOUT[15:0];
   end // always @ (DIN or SHIFT)
endmodule // shifter

This synthesises to a ROM table and a shifter which is what I want. However
xst warns me that SHIFTp and TMPOUT are assigned but never used. I presume
that it optimised them away or something.

It also complains that SHIFTp is not in the sensitivity list of the always
block.. Seems rather odd to me..

>> Strangely I find that the results are fine but the final FIFO is either
>> not clocking the data in properly, or not clocking it out properly..
>>
> This might be a clue as to where timing is being violated.  Since this
> was from an 'old' board I'm guessing that the FIFOs there were the
> garden variety async FIFOs.  Hopefully inside the FPGA you didn't try
> to implement that but used a standard synchronous type instead.

Yes they're async - IDT 720x.

I am using the async FIFO core from Xilinx's coregen (and an ALU).
 
>> However if I test it in isolation it works fine.
> When you're testing it in isolation though I'll bet that the timing in
> and out of the FIFO is not really the same as it is when inside the
> full FPGA.  When testing in isolation, if you were to apply stimulus at
> the exact same time to this isolated FIFO it would not work in the same
> manner as you're seeing it not work for you now.

Hmm OK..
What a pain :)
 
> If it is a synchronous FIFO then are the clocks free running or gated?
> If gated, then how that gating logic is implemented could be the
> problem (once again though, this is just a manifestation of a timing
> failure which can also be caught by full static timing analysis).

It is an async core, although the clock signal is not free running, it is
generated off the card by a PLD which is gating another clock.
Unfortunately I can't change that aspect :(

Based on my reading of the datasheet I don't think that is a problem as such
because the only problem I would have is that the flags won't get updated,
but this design does not use them.

>> I have applied some basic timing constraints, and when looking at the
>> resulting timing diagrams it seems that there is plenty of time for the
>> data to be valid on the input side of the final FIFO before the write
>> clock is applied.
> 
> What about all the timing inside of the device though?  What is the
> timing report telling you there?  If there are multiple clocks involved
> then moving data from one clock domain to the other needs to be done
> properly.

The thing is that the "clocks" aren't free running at all, they're all
derived from the same base clock and gated with a PLD (or 3) and then piped
down the backplane to the card I am designing.

So I think in practise I am not actually going from one clock domain to
another..

I captured some sample signal information and have been using that as my
test suite. In it, the control signals for the final FIFO where I am seeing
the problem the data is clocked in and then clocked out later - at no time
are both sides of the FIFO being clocked..

I'm about to see if there is a way to peer inside the FIFO black box so I
can tell if it's the read or write side that is at issue.

Thanks for your reply!

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C



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