Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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 CurtArticle: 133901
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
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
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 PollumArticle: 133904
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: 133905Xilinx 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: DE130097310Article: 133906
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.comArticle: 133907
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
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<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: DE130097310Article: 133910
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. RickArticle: 133911
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.comArticle: 133912
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 McCaskillArticle: 133913
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 McCaskillArticle: 133914
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
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 AnttiArticle: 133916
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, SeanArticle: 133917
Hi, See http://www.xilinx.com/company/videos/index.htm and http://www.xilinx.com/events/webcasts_od.htm Regards.Article: 133918
"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. > > RickArticle: 133919
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: 133920I 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 helpArticle: 133921
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. - BrianArticle: 133922
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, JordiArticle: 133923
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: 133924On 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:
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