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 133900

Article: 133900
Subject: Virtex-5, DDR2 SRAM, and ISERDES
From: Pete <petersen.curt@gmail.com>
Date: Fri, 18 Jul 2008 11:23:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
Is it not recommended to use the ISERDES in the Virtex-5 to perform
strobe-based read capture from a DDR2 SRAM (not QDR) part?  I'm
routing my echo clock (CQ)  into the FPGA through an IODELAY
component, then BUFIOs, and then straight to the 18 DQ pins (ISERDES
blocks) using local clock routing.  I'm seeing random bit errors that
I attribute to the read capture path.  Based on the errors, I think it
might have something to do with the CQ and CLK phase relationship, but
I'm not sure.  I'm calibrating the read path using the 3 stage
technique described in XAPP858.  I'm seeing some good valid windows
delaying my individual DQ data variably.  I'm not getting any errors
when I delay the DQ and CQ in lock-step in phase 2.

I just looked at the RTL vhdl code generated by the MIG for a DDR2
SDRAM controller and found that the ISERDES aren't used.  Instead, the
data is clocked in by an IDDR flop, and then directly into carefully
placed fabric flip-flops (using a phenomenal number of directed
routing constraint attributes).

Could someone explain to me when using ISERDES for strobe-based read
capture is applicable, versus using the IDDR + hand-placed fabric flip-
flops?

Thank you.
-Petersen Curt

Article: 133901
Subject: Re: Which FPGA has most ram in a TQFP144 or smaller non-BGA?
From: Gabor <gabor@alacron.com>
Date: Fri, 18 Jul 2008 11:32:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 18, 2:17 pm, cs_post...@hotmail.com wrote:
> Which affordable FPGA has the most dual port block-ram type resources
> in a TQFP144 or smaller
> quad flat pack (non-BGA) package, that's actually stocked by
> distributors?
>
> I/O requirements and internal logic are fairly limited, but I need a
> lot of buffer memory and to fit the device on a very narrow PCB
> without the assembly issues of a BGA package.
>
> So far spartan XC3S200 or XC3S250E with 12 x 16K-bit block rams seems
> the largest memory in a device that fully meets this constraint.
>
> I'd really like the 16 block rams of the 400 or 500 gate parts or
> more, but squeezing in the PQFP-208 they come in is going to be dicey,
> and I'd like to avoid going to a BGA package.
>
> Altera does not seem to offer the mid-size cyclones in quad flat
> packs, or at least they aren't stocked.
>
> Any other makers with interesting parts?

Lattice has several offerings in TQ144, all unfortunately with the
same block RAM capacity as your Spartans (12 x 18 Kb).

Article: 133902
Subject: Re: Xilinx/Altera gate equivalence
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 18 Jul 2008 18:46:47 GMT
Links: << >>  << T >>  << A >>
Lorenz Kolb <lorenz.kolb@uni-ulm.de> wrote:

>Bert wrote:
>> On 17 jul, 05:00, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
>> Murray) wrote:
>>>> Anyway, this is not an academic exercise. Porting a very complex
>>>> Virtex4 design
>>>> to Stratix is not something that one can do in a few days, so I was
>>>> looking
>>>> for ballpark estimates about the equivalence between Xilinx and Altera
>>>> "gates".
>>> Have you looked at the Stratix data sheet?  Did you find anything
>>> close to a CLB/FF pair?  If so, assume they are 1:1.
>>>
>>> Then count the special things you use: BRAMs, clock buffers, multipliers
>>> and whatevber.  Then see if Altera has something similar.
>>>
>>> --
>>> These are my opinions, not necessarily my employer's.  I hate spam.
>> 
>> Hi,
>> 
>> I have searched before about the comparison Logic Elements and Logic
>> Cells. Most of the result say LE = LC, but once (@ Altera website) I
>> found that LE = 1.125*LC
>> 
>> Bye
>> Bert
>
>This highly depends on the actual design, there are some minor 
>differences between LEs and LCs that might or might not have an 
>advantage for certain designs. Nevertheless estimating 1:1 is a fairly 
>good choice in my opinion. At least as long as you do not want to go 
>without any reserve of LEs/LCs.


I don't think so. I guess the best estimate is to determine the amount
of flipflops in use in both normal flipflops and LUT ram. You'll need
an Altera device with at least that amount of flipflops. Next thing
you'll need to compare blockrams, multipliers, etc. But the latter is
relatively easy.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 133903
Subject: Re: free of bugs
From: Dave Pollum <vze24h5m@verizon.net>
Date: Fri, 18 Jul 2008 11:54:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 18, 12:42=A0am, hmmudassi...@gmail.com wrote:
> On Jul 17, 4:59=A0pm, Lorenz Kolb <lorenz.k...@uni-ulm.de> wrote:
>
> > hmmudassi...@gmail.com wrote:
> > > Please =A0tell me any link =A0from =A0i would easily download usb cor=
e which
> > > will be free of bugs.
>
> > have you already tried asking in comp.do.my.work or
> > comp.do.my.work.for.free ?
>
> sir
> I am trying by writting these "comp.do.my.work.for.free" and
> "comp.do.my.work" but page is not opening
> comp.arch.fpga is opening

The replies you are getting are "suggesting" that you do more research
on your own, before posting here.  Using Google works well.
-Dave Pollum

Article: 133904
Subject: Additional Hardware Module with Xilinx MicroBlaze Processor
From: "Ray D." <ray.delvecchio@gmail.com>
Date: Fri, 18 Jul 2008 13:21:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hey all,

I have a Xilinx Spartan-3E starter board, and I'm implementing a
MicroBlaze processor on the FPGA.  I would also like to use the LCD
which is on board, and I have already developed a hardware module that
takes care of initialization and printing to the LCD.  The interface
is shown below:

entity LCD_top is
    Port (
	   clk : in  STD_LOGIC;
           reset : in  STD_LOGIC;

	   din : in STD_LOGIC_VECTOR (7 downto 0);
	   din_ready : in STD_LOGIC;
	   busy : out STD_LOGIC;

           LCD_D : out  STD_LOGIC_VECTOR (11 downto 8);
           LCD_E : out  STD_LOGIC;
           LCD_RS : out  STD_LOGIC;
           LCD_RW : out  STD_LOGIC

	);
end LCD_top;

I really would like to instantiate this module along with the
processor core.  My question is this - how would I go about
interfacing this with the MicroBlaze processor internal to the FPGA?
What I would like to do is define a GPIO port on the processor to
connect to the din, din_ready and busy lines of the LCD module, but I
keep getting the following error:

ERROR:MDT - INST:LCD_data_status_10Bit PORT:GPIO_IO
   CONNECTOR:LCD_data_status_10Bit_GPIO_IO - C:\EDK_Test_LCD
\system.mhs line 150
   - connection is not connected to an external port!
   MPD subproperties IOB_STATE=BUF|REG or THREE_STATE=TRUE require
that the port
   be connected directly to an external port.

Is there any way to work around this?  I realize I could just connect
the LCD to the GPIO directly and write software drivers, but I'm
trying to avoid that because I already have the hardware module in
place and working smoothly.  It will also be nice to have this
separate module so that it does the work of printing to the LCD, and
the processor itself can stay busy with other more important jobs.

Also, is there an easier way to add another hardware module without
manually editing the generated VHDL files for the core?  I'm not sure
if you can do that within Platform Studio.

Any advice would be much appreciated, thanks!

Ray

Article: 133905
Subject: Re: Which FPGA has most ram in a TQFP144 or smaller non-BGA?
From: "M.Randelzhofer" <techseller@gmx.de>
Date: Fri, 18 Jul 2008 22:47:21 +0200
Links: << >>  << T >>  << A >>
Xilinx Spartan3 XC3S400 has 16 18k Blockrams, Spartan 3E & 3A only has less 
BRAMs FPGA's in TQ144.

see:
http://www.xilinx.com/support/documentation/data_sheets/ds099.pdf

However the VQ100 XC3S500E has 20 18k Blockrams.
see:
http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf

BGA rulez.

MIKE

-- 
www.oho-elektronik.de
OHO-Elektronik
Michael Randelzhofer
FPGA und CPLD Mini Module
Klein aber oho !
Kontakt:
Tel: 08131 339230
mr@oho-elektronik.de
Usst.ID: DE130097310 



Article: 133906
Subject: Re: Additional Hardware Module with Xilinx MicroBlaze Processor
From: John McCaskill <jhmccaskill@gmail.com>
Date: Fri, 18 Jul 2008 14:08:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 18, 1:21=A0pm, "Ray D." <ray.delvecc...@gmail.com> wrote:
> Hey all,
>
> I have a Xilinx Spartan-3E starter board, and I'm implementing a
> MicroBlaze processor on the FPGA. =A0I would also like to use the LCD
> which is on board, and I have already developed a hardware module that
> takes care of initialization and printing to the LCD. =A0The interface
> is shown below:
>
> entity LCD_top is
> =A0 =A0 Port (
> =A0 =A0 =A0 =A0 =A0 =A0clk : in =A0STD_LOGIC;
> =A0 =A0 =A0 =A0 =A0 =A0reset : in =A0STD_LOGIC;
>
> =A0 =A0 =A0 =A0 =A0 =A0din : in STD_LOGIC_VECTOR (7 downto 0);
> =A0 =A0 =A0 =A0 =A0 =A0din_ready : in STD_LOGIC;
> =A0 =A0 =A0 =A0 =A0 =A0busy : out STD_LOGIC;
>
> =A0 =A0 =A0 =A0 =A0 =A0LCD_D : out =A0STD_LOGIC_VECTOR (11 downto 8);
> =A0 =A0 =A0 =A0 =A0 =A0LCD_E : out =A0STD_LOGIC;
> =A0 =A0 =A0 =A0 =A0 =A0LCD_RS : out =A0STD_LOGIC;
> =A0 =A0 =A0 =A0 =A0 =A0LCD_RW : out =A0STD_LOGIC
>
> =A0 =A0 =A0 =A0 );
> end LCD_top;
>
> I really would like to instantiate this module along with the
> processor core. =A0My question is this - how would I go about
> interfacing this with the MicroBlaze processor internal to the FPGA?
> What I would like to do is define a GPIO port on the processor to
> connect to the din, din_ready and busy lines of the LCD module, but I
> keep getting the following error:
>
> ERROR:MDT - INST:LCD_data_status_10Bit PORT:GPIO_IO
> =A0 =A0CONNECTOR:LCD_data_status_10Bit_GPIO_IO - C:\EDK_Test_LCD
> \system.mhs line 150
> =A0 =A0- connection is not connected to an external port!
> =A0 =A0MPD subproperties IOB_STATE=3DBUF|REG or THREE_STATE=3DTRUE requir=
e
> that the port
> =A0 =A0be connected directly to an external port.
>
> Is there any way to work around this? =A0I realize I could just connect
> the LCD to the GPIO directly and write software drivers, but I'm
> trying to avoid that because I already have the hardware module in
> place and working smoothly. =A0It will also be nice to have this
> separate module so that it does the work of printing to the LCD, and
> the processor itself can stay busy with other more important jobs.
>
> Also, is there an easier way to add another hardware module without
> manually editing the generated VHDL files for the core? =A0I'm not sure
> if you can do that within Platform Studio.
>
> Any advice would be much appreciated, thanks!
>
> Ray


The "IOB_STATE=3DBUF|REG" part of the error message means that the GPIO
core is instantiating IOB primitives in its code instead of letting
Platgen infer them. That means that this core will not be happy unless
those ports are made external and go to FPGA pins.

I would suggest creating a simple OPB interface to your core.  The OPB
bus is simple, and creating a slave interface to what you show above
would not be hard.

The OPB is documented in $EDK/third_party/doc/OpbBus.pdf. That might
be part of the IBM CoreConnect Bus Functional Model tool kit. If it
is, you just register for the tool kit on the Xilinx web site to get
access to it.

For you second question, did you package your LCD code as an EDK
Pcore?  If you do that, you can add the core through the GUI.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 133907
Subject: Re: Which FPGA has most ram in a TQFP144 or smaller non-BGA?
From: cs_posting@hotmail.com
Date: Fri, 18 Jul 2008 14:52:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 18, 4:47 pm, "M.Randelzhofer" <techsel...@gmx.de> wrote:

> However the VQ100 XC3S500E has 20 18k Blockrams.
> see:http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf

Thanks - I had not realized this was a possibility.  An XC3S500E in a
VQ100 would be perfect, but the question with obscure die  / package
combos is if they actually make any of them on a regular basis, or
only if someone orders a hundred thousand and is willing to wait a few
months.

Unfortunately, I'm not seeing anything bigger than the 3S250E actually
for sale in the VQ100 package.

Article: 133908
Subject: Re: Which FPGA has most ram in a TQFP144 or smaller non-BGA?
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 18 Jul 2008 15:04:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 18, 2:52=A0pm, cs_post...@hotmail.com wrote:
> On Jul 18, 4:47 pm, "M.Randelzhofer" <techsel...@gmx.de> wrote:
>
> > However the VQ100 XC3S500E has 20 18k Blockrams.
> > see:http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf
>
> Thanks - I had not realized this was a possibility. =A0An XC3S500E in a
> VQ100 would be perfect, but the question with obscure die =A0/ package
> combos is if they actually make any of them on a regular basis, or
> only if someone orders a hundred thousand and is willing to wait a few
> months.
>
> Unfortunately, I'm not seeing anything bigger than the 3S250E actually
> for sale in the VQ100 package.

Xilinx is not in the custom IC or package  business.
If ("when" in this case) it is in the data sheet, then your
distributor should either have it on the shelf, or can order it for
you.
That's their job.
Peter Alfke

Article: 133909
Subject: Re: Which FPGA has most ram in a TQFP144 or smaller non-BGA?
From: "M.Randelzhofer" <techseller@gmx.de>
Date: Sat, 19 Jul 2008 03:13:34 +0200
Links: << >>  << T >>  << A >>
<cs_posting@hotmail.com> schrieb im Newsbeitrag 
news:8ef3c779-a9d6-48ea-8a2b-4b4bad01cd86@b1g2000hsg.googlegroups.com...
> On Jul 18, 4:47 pm, "M.Randelzhofer" <techsel...@gmx.de> wrote:
>
>> However the VQ100 XC3S500E has 20 18k Blockrams.
>> see:http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf
>
> Thanks - I had not realized this was a possibility.  An XC3S500E in a
> VQ100 would be perfect, but the question with obscure die  / package
> combos is if they actually make any of them on a regular basis, or
> only if someone orders a hundred thousand and is willing to wait a few
> months.
>
> Unfortunately, I'm not seeing anything bigger than the 3S250E actually
> for sale in the VQ100 package.

The new package options for S3E and S3A seem not to be available @ digikey 
at the moment.

8 weeks ago, i ordered a few of the XC3S500E-4VQG100C parts @ silica,
delivery time was advertised to be 26 weeks, but after 2 weeks they were on 
my table.

Similar delivery situation with XC3S50A-4VQG100C. After 1 week, i had them.
I'm still waiting for the XC3S200A-4VQG100C, which are announced to be 
delivered in August 2008.

Some more package options for the S3AN would be very appreciated in the 
industrial environment.
Product managers often are (very) afraid of the possibility, that one bit in 
the configuration memory of the FPGA is toggling by SEU.
S3AN seems to be the best solution for configuration bit verification during 
operation.
Maybe there is a serious space problem for the 2 chip S3AN, which doesn't 
allow a XC3S400A-TQG144C.

MIKE

-- 
www.oho-elektronik.de
OHO-Elektronik
Michael Randelzhofer
FPGA und CPLD Mini Module
Klein aber oho !
Kontakt:
Tel: 08131 339230
mr@oho-elektronik.de
Usst.ID: DE130097310 



Article: 133910
Subject: The littlest CPU
From: rickman <gnuarm@gmail.com>
Date: Fri, 18 Jul 2008 20:07:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
I may need to add a CPU to a design I am doing.  I had rolled my own
core once with a 16 bit data path and it worked out fairly well.  But
it was 600 LUT/FFs and I would like to use something smaller if
possible.  The target is a Lattice XP3 with about 3100 LUT/FFs and
about 2000 are currently used.  I believe that once I add the CPU
core, I can take out a lot of the logic since it runs so slowly.  The
fastest parallel data rate is 8 kHz with some at 1 kHz and the rest at
100 Hz.  I probably would have used a CPU to start with instead of the
FPGA, but there was a possible need to handle higher speed signals
which seems to have gone away.

I recall that someone had started a thread about serial
implementations of processors that were supported by a C compiler.  I
don't think any ever turned up.  But the OP had some other
requirements that may have excluded a few very small designs.  Are
there any CPU cores, serial or parallel, that are significantly
smaller than 600 LUT/FFs?  The Lattice part has LUT memory even dual
port, so that is not a constraint, the LUTs can be used for
registers.

Rick

Article: 133911
Subject: Re: The littlest CPU
From: John McCaskill <jhmccaskill@gmail.com>
Date: Fri, 18 Jul 2008 21:09:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 18, 10:07=A0pm, rickman <gnu...@gmail.com> wrote:
> I may need to add a CPU to a design I am doing. =A0I had rolled my own
> core once with a 16 bit data path and it worked out fairly well. =A0But
> it was 600 LUT/FFs and I would like to use something smaller if
> possible. =A0The target is a Lattice XP3 with about 3100 LUT/FFs and
> about 2000 are currently used. =A0I believe that once I add the CPU
> core, I can take out a lot of the logic since it runs so slowly. =A0The
> fastest parallel data rate is 8 kHz with some at 1 kHz and the rest at
> 100 Hz. =A0I probably would have used a CPU to start with instead of the
> FPGA, but there was a possible need to handle higher speed signals
> which seems to have gone away.
>
> I recall that someone had started a thread about serial
> implementations of processors that were supported by a C compiler. =A0I
> don't think any ever turned up. =A0But the OP had some other
> requirements that may have excluded a few very small designs. =A0Are
> there any CPU cores, serial or parallel, that are significantly
> smaller than 600 LUT/FFs? =A0The Lattice part has LUT memory even dual
> port, so that is not a constraint, the LUTs can be used for
> registers.
>
> Rick


The Xilinx PicoBlaze is less than 100 LUTs plus one block ram.
Someone has been working on a simple C compiler for the PicoBlaze, but
I have not tried it yet.  I have used the PicoBlaze in many projects
and I am quite happy with it.

I have not used it, but Lattice has the Micro8.  Have you looked at
it?  It has been mentioned here as the Lattice equivalent to the
PicoBlaze.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 133912
Subject: Re: The littlest CPU
From: John McCaskill <jhmccaskill@gmail.com>
Date: Fri, 18 Jul 2008 21:23:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 18, 11:09=A0pm, John McCaskill <jhmccask...@gmail.com> wrote:

>
> The Xilinx PicoBlaze is less than 100 LUTs plus one block ram.

That should be less than 100 slices.

Regards,

John McCaskill

Article: 133913
Subject: Re: The littlest CPU
From: "beky4kr@gmail.com" <beky4kr@gmail.com>
Date: Fri, 18 Jul 2008 21:39:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
If a 8 bits CPU is fine you may want to see my site. There is VHDL or
verilog design. For this CPU it is easy to find free or non free
tools. All is discussed in detail at:
http://bknpk.no-ip.biz/usb_1.html

"I used 8051 from http://www.cs.ucr.edu/~dalton/i8051/i8051syn. The
VHDL code has been translated to verilog to avoid mix languages
simulation. The cpu is also slightly modified to be able to use XILINX
memories: for ROM I use..."



On 19 =D7=99=D7=95=D7=9C=D7=99, 07:23, John McCaskill <jhmccask...@gmail.co=
m> wrote:
> On Jul 18, 11:09 pm, John McCaskill <jhmccask...@gmail.com> wrote:
>
>
>
> > The Xilinx PicoBlaze is less than 100 LUTs plus one block ram.
>
> That should be less than 100 slices.
>
> Regards,
>
> John McCaskill


Article: 133914
Subject: Re: Nintendo DS Screenshots / Video Capture
From: cs_posting@hotmail.com
Date: Fri, 18 Jul 2008 22:19:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 1, 8:00 pm, Paul Urbanus <urbpub...@hotmail.com> wrote:

> I'm not a verilog person, but here's the basic functional flow.
>
> 1. Implement a counter with a count length of 263 (counts from 0 to
> 262). This will be used to determine the horizontal position of the pixels.
> 2. Detect either the rising or falling edge of VSYNC - pick one and only
> one edge.
> 3. Use the detected VSYNC edge to load your horizontal counter with a
> specific value, initially to zero. If your image is shifted horizontally
> after you grab a frame, then adjust this preload value to get the image
> properly horizontally positioned.
> 4. Implement a second counter which keeps track of the line number of
> the screen image. Clear this counter with the detected VSYNC edge
> generate in step 2.
> 5. Increment the vertical counter from step 4 whenever the horizontal
> counter value is 262 (max count).

Actually the simplest thing to do may be to do a one-dimensional
recording of as many bits as will fit in the SRAM, triggered by the
vsync.  Dump the whole thing over the serial port and sort it out with
software on the PC where you can more easily see what you are doing.
If this proves to be inadequate, you can then re-design the fpga logic
to do a more targeted aquisition based on what you've learned.  For
example, if there's a lot of dead time between lines (it's not a CRT
with a beam that needs to retrace, but I suppose this could still
occur) you'd be wasting memory recording that, but you might still
have enough.

I'd build a circuit that's 'armed' by any activity on the RS232 RxD
line, is 'triggered' by the VSYNC, and once it's data is available
dumps all of it over the RS232 TxD.  You can find example RS232
transmitters online, and in this case you don't need a real receiver
in the fpga, just something that you can arm by having your computer
send an arbitrary character to it, after which it will reply with the
next available frame.

Article: 133915
Subject: Re: The littlest CPU
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 18 Jul 2008 23:57:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 19 juuli, 06:07, rickman <gnu...@gmail.com> wrote:
> I may need to add a CPU to a design I am doing. =A0I had rolled my own
> core once with a 16 bit data path and it worked out fairly well. =A0But
> it was 600 LUT/FFs and I would like to use something smaller if
> possible. =A0The target is a Lattice XP3 with about 3100 LUT/FFs and
> about 2000 are currently used. =A0I believe that once I add the CPU
> core, I can take out a lot of the logic since it runs so slowly. =A0The
> fastest parallel data rate is 8 kHz with some at 1 kHz and the rest at
> 100 Hz. =A0I probably would have used a CPU to start with instead of the
> FPGA, but there was a possible need to handle higher speed signals
> which seems to have gone away.
>
> I recall that someone had started a thread about serial
> implementations of processors that were supported by a C compiler. =A0I
> don't think any ever turned up. =A0But the OP had some other
> requirements that may have excluded a few very small designs. =A0Are
> there any CPU cores, serial or parallel, that are significantly
> smaller than 600 LUT/FFs? =A0The Lattice part has LUT memory even dual
> port, so that is not a constraint, the LUTs can be used for
> registers.
>
> Rick

im OP

hi I may have different interests, yes smallest nonserialized CPU
as for your current task is one of the wishes, and here also there
is no one definitive winner

pico paco blazes and mico8 are out of the question, most others
are too large

i have used cut AVR core in XP3 but i dont recall the lut count

Antti



Article: 133916
Subject: Re: Virtex-5, DDR2 SRAM, and ISERDES
From: Sean Durkin <news_jul08@durkin.de>
Date: Sat, 19 Jul 2008 09:26:09 +0200
Links: << >>  << T >>  << A >>
Pete wrote:
> Could someone explain to me when using ISERDES for strobe-based read
> capture is applicable, versus using the IDDR + hand-placed fabric flip-
> flops?

I've only used the DDR2-SDRAM-Core, and there you can select if you want 
to use ISERDES or not. Don't know if this applies to the DDR2-SRAM-core 
as well.

As to why the ISERDES aren't used in the DDR2-SRAM-code from MiG I can 
only speculate:

If you want to use ISERDES, you need the clocks returned from the memory 
device connected to the right (i.e. clock capable) pins, plus the 
corresponding data bits need to be connected to FPGA pins in the same 
clock region (as obviuosly is the case on your board). This can make 
board layout more complicated, you might run into problems with the SSO 
threshold and so on. All in all, you're not as flexible. If you don't 
use the ISERDES, it pretty much doesn't matter which pins you use, even 
though the FPGA design is more complicated. This approach even works if 
you didn't think of the pinout constraints when designing the hardware.

I suspect the DDR2-SRAM-core originated in an xapp that was made for 
some Xilinx evaluation board that didn't use the right FPGA pins, so 
they had to do it this way. Or it was designed for older parts like 
Virtex2 Pro that don't have ISERDES anyway. They probably simply haven't 
had the time (or the incentive, i.e. a customer request) to "port" it to 
ISERDES.

For the DDR2-SDRAM-core the ISERDES-solution was released long after the 
other one as well. Maybe the application engineers can't keep up with 
guys that develop the new silicon :)

HTH,
Sean

Article: 133917
Subject: Re: free video course fpga or asic
From: Alain <no_spa2005@yahoo.fr>
Date: Sat, 19 Jul 2008 00:39:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

See http://www.xilinx.com/company/videos/index.htm and
http://www.xilinx.com/events/webcasts_od.htm

Regards.



Article: 133918
Subject: Re: The littlest CPU
From: "HT-Lab" <hans64@ht-lab.com>
Date: Sat, 19 Jul 2008 08:55:19 +0100
Links: << >>  << T >>  << A >>

"rickman" <gnuarm@gmail.com> wrote in message 
news:d9ecb5e5-5712-4430-8156-375bbf0ec7fd@z66g2000hsc.googlegroups.com...
>I may need to add a CPU to a design I am doing.  I had rolled my own
> core once with a 16 bit data path and it worked out fairly well.  But
> it was 600 LUT/FFs and I would like to use something smaller if
> possible.  The target is a Lattice XP3 with about 3100 LUT/FFs and
> about 2000 are currently used.  I believe that once I add the CPU
> core, I can take out a lot of the logic since it runs so slowly.  The
> fastest parallel data rate is 8 kHz with some at 1 kHz and the rest at
> 100 Hz.  I probably would have used a CPU to start with instead of the
> FPGA, but there was a possible need to handle higher speed signals
> which seems to have gone away.
>
> I recall that someone had started a thread about serial
> implementations of processors that were supported by a C compiler.  I
> don't think any ever turned up.  But the OP had some other
> requirements that may have excluded a few very small designs.  Are
> there any CPU cores, serial or parallel, that are significantly
> smaller than 600 LUT/FFs?

I would suggest you check out one of the many free PIC cores available on 
the web. The reason for suggesting PIC is that it is accompanied by a 
processional IDE from Microchip. Developing a processor is easy and the web 
is full of wonderful and clever implementation but at the end of the day if 
you have to develop some software you need a good IDE.

I just tried a quick push-button synthesis of a 16C54,

***********************************************
Device Utilization for LFXP3C/PQFP208
***********************************************
Resource                Used    Avail   Utilization
-----------------------------------------------
LUTs                    374     3072     12.17%
Flipflops               83      3072      2.70%
Block RAMs              0       6         0.00%
IOs                     67      136      49.26%
-----------------------------------------------

Hans
www.ht-lab.com



> The Lattice part has LUT memory even dual
> port, so that is not a constraint, the LUTs can be used for
> registers.
>
> Rick 



Article: 133919
Subject: Re: Which FPGA has most ram in a TQFP144 or smaller non-BGA?
From: Mike Harrison <mike@whitewing.co.uk>
Date: Sat, 19 Jul 2008 09:55:32 +0100
Links: << >>  << T >>  << A >>
On Fri, 18 Jul 2008 15:04:16 -0700 (PDT), Peter Alfke <peter@xilinx.com> wrote:

>On Jul 18, 2:52 pm, cs_post...@hotmail.com wrote:
>> On Jul 18, 4:47 pm, "M.Randelzhofer" <techsel...@gmx.de> wrote:
>>
>> > However the VQ100 XC3S500E has 20 18k Blockrams.
>> > see:http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf
>>
>> Thanks - I had not realized this was a possibility.  An XC3S500E in a
>> VQ100 would be perfect, but the question with obscure die  / package
>> combos is if they actually make any of them on a regular basis, or
>> only if someone orders a hundred thousand and is willing to wait a few
>> months.
>>
>> Unfortunately, I'm not seeing anything bigger than the 3S250E actually
>> for sale in the VQ100 package.
>
>Xilinx is not in the custom IC or package  business.
>If ("when" in this case) it is in the data sheet, then your
>distributor should either have it on the shelf, or can order it for
>you.

..but the problem with distributors tends to be that for a less-than popular  item,  there is often
a significant MOQ - like a tray-full. 
Do Xilinx supply small qtys to distributors?


Article: 133920
Subject: Howto disable Quartus infering M4Ks??
From: tgau3qk4@gmail.com
Date: Sat, 19 Jul 2008 02:13:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have some problems with a design I am porting from Xilinx to Altera.
The fitter dies with a message about the design not fitting into the
device.Further investiogation shows that Quartus tries to move a lot
of small shiftregisters (32-bit x 4) into M4Ks, which is a not the
best use of my embedded memories...

Can anyone explain to me why this happens? I am using 75% of the FPGA
right now and should be able to get the small shift registers into
LEs. Is there any way to let Quartus infer none or _some_ of the shift
registers into M4Ks and use LEs for the rest??


(I am using Quartus Webpack version 8.0, build 231 07/10/2008)

thanks for any help

Article: 133921
Subject: Re: Additional Hardware Module with Xilinx MicroBlaze Processor
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 19 Jul 2008 13:40:42 +0100
Links: << >>  << T >>  << A >>
On Fri, 18 Jul 2008 13:21:54 -0700 (PDT), "Ray D."
<ray.delvecchio@gmail.com> wrote:

>Hey all,
>
>I have a Xilinx Spartan-3E starter board, and I'm implementing a
>MicroBlaze processor on the FPGA.  I would also like to use the LCD
>which is on board, and I have already developed a hardware module that
>takes care of initialization and printing to the LCD.  The interface
>is shown below:
>
>entity LCD_top is
>    Port (
>	   clk : in  STD_LOGIC;
>           reset : in  STD_LOGIC;
>
>	   din : in STD_LOGIC_VECTOR (7 downto 0);
>	   din_ready : in STD_LOGIC;
>	   busy : out STD_LOGIC;
>
>           LCD_D : out  STD_LOGIC_VECTOR (11 downto 8);
>           LCD_E : out  STD_LOGIC;
>           LCD_RS : out  STD_LOGIC;
>           LCD_RW : out  STD_LOGIC
>
>	);
>end LCD_top;
>
>I really would like to instantiate this module along with the
>processor core.  My question is this - how would I go about
>interfacing this with the MicroBlaze processor internal to the FPGA?

The problem is that EDK basically wants all EDK blocks in its design,
and assumes that anything you want to do can be done with EDK blocks,
such as GPIO.

I agree with John that you probably want an OPB bus interface to the LCD
device; the question is the easiest way to create one.

The OPB bus looks complex, if you take all the optional features into
account. John's view is that it isn't, but if you need DMA or other
special features it may get tricky. Using DMA, I have seen bugs in the
Xilinx-supplied cores (in the EDK 7.1 era) which either shows it's
complex, or suggests you roll your own in place of the vendor cores!

If you don't want to delve straight into OPB, look at the "OPB IPIF"
module which is a starting point for your own OPB core. What I did with
this was to add whatever I/O signals I wanted (e.g. to talk to your LCD
interface) to the IPIF top level, and simply connect them up to the IPIF
interface internally, in the section indicated for user logic. 

I did it this way because the EDK project was a small bolt-on to a large
project. It would be more straightforward to instantiate the LCD
controller in the IPIF user logic area; and thus wrap it as an EDK
block.

I'm not recommending this as a better option than rolling your own OPB
core, but it's an alternative worth looking at; possibly simpler for a
first EDK project.

- Brian


Article: 133922
Subject: Xilinx EDK OPB bus compatibility
From: Jordi <a80x86@gmail.com>
Date: Sat, 19 Jul 2008 05:59:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I'm new in FPGA design and I have a question about Xilinx EDK. There
are different versions of the OPB bus. Some cores use newest versions
but others use older versions. So how can I use different cores if
they use different versions of the OPB bus?. Can I put one bridge for
every version of the bus connected all to the PLB bus.


Thanks in advance,

Jordi

Article: 133923
Subject: Re: Howto disable Quartus infering M4Ks??
From: Mike Treseler <mtreseler@gmail.com>
Date: Sat, 19 Jul 2008 07:03:33 -0700
Links: << >>  << T >>  << A >>
tgau3qk4@gmail.com wrote:
> I have some problems with a design I am porting from Xilinx to Altera.
> The fitter dies with a message about the design not fitting into the
> device.Further investiogation shows that Quartus tries to move a lot
> of small shiftregisters (32-bit x 4) into M4Ks, which is a not the
> best use of my embedded memories...

Try running quartus with no constraints other than
the device family.

        -- Mike Treseler

Article: 133924
Subject: Re: Howto disable Quartus infering M4Ks??
From: Subroto Datta <sdatta@altera.com>
Date: Sat, 19 Jul 2008 07:33:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 19, 2:13=A0am, tgau3...@gmail.com wrote:
> I have some problems with a design I am porting from Xilinx to Altera.
> The fitter dies with a message about the design not fitting into the
> device.Further investiogation shows that Quartus tries to move a lot
> of small shiftregisters (32-bit x 4) into M4Ks, which is a not the
> best use of my embedded memories...
>
> Can anyone explain to me why this happens? I am using 75% of the FPGA
> right now and should be able to get the small shift registers into
> LEs. Is there any way to let Quartus infer none or _some_ of the shift
> registers into M4Ks and use LEs for the rest??
>
> (I am using Quartus Webpack version 8.0, build 231 07/10/2008)
>
> thanks for any help

In the Quartus UI use the Assignments menu as folows : Assiginmnets-
>Settings->Analysis & Synthesis Settings->More Settings . Scroll down
in the dialog t a set of Maximum Setting entries which look like
Maximm Number of M512 memory blocks. Set it to 0 or any non zero
number other than -1 (which is default).

Hope tis helps,
Subroto Datta
Altera Corp.



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