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
On Oct 14, 11:55=A0pm, PatC <p...@REMOVETHISpatocarr.com> wrote: > niklas_mo...@hotmail.com wrote: > > Hi. > > > I have a design with a Virtex 5 and a DDR2 memory. > > It seems like there is some problem when I read from the DDR2 memory > > and I was hoping that someone here might recognize the problem. > > > Here is what happens. > > My base address for the memory is 0x88000000 > > > I write following bytes (byte write) 0x11 to 0x88000000, 0x22 to > > 0x88000001, 0x33 to 0x88000002, 0x44 to 0x88000003. > > > When I read from the memory it will look like (32 bits format): > > 0x88000000 =A0 =A0 =A0 =A011000000 > > 0x88000004 =A0 =A0 =A0 =A000000000 > > 0x88000008 =A0 =A0 =A0 =A000000000 > > 0x8800000C =A0 =A0 =A0 =A000000000 > > 0x88000010 =A0 =A0 =A0 =A000223344 > > > But sometimes it seems to work and then I try to reload the bit-file > > and then I get the same problem again. > > What I notice is that when it works I write i.e 0x11223344 and will > > read back > > 0x88000000 =A0 =A0 =A0 =A011223344 > > 0x88000004 =A0 =A0 =A0 =A000000000 > > 0x88000008 =A0 =A0 =A0 =A000000000 > > 0x8800000C =A0 =A0 =A0 =A000000000 > > 0x88000010 =A0 =A0 =A0 =A000000000 > > > If I reload the bit-file I will read back: > > 0x88000000 =A0 =A0 =A0 =A011000000 > > 0x88000004 =A0 =A0 =A0 =A000000000 > > 0x88000008 =A0 =A0 =A0 =A000000000 > > 0x8800000C =A0 =A0 =A0 =A000000000 > > 0x88000010 =A0 =A0 =A0 =A000223344 > > > So my conclusion is that the write part always seems to work, but it > > the read part that doesn't work. > > Could the be a problem with the IDELAYCTRL that is not calibrated? > > > Thanks, > > Niklas > > Hi Niklas, > > =A0 =A0Your question is quite broad and lacks details. > > - Which controller are you using? MIG-generated, your own, etc. > > - What SDRAM type is it? 4-burst length? > > - When you say base address, are you using an embedded processor? > > - Does it work in simulation? *g* > > Cheers, > -Pat Hi Pat. Yes, I'm using a Microblaze (EDK) and the controller is MPMC 3.0 and the also used the MIG-generator. The burst length is 8 and the memory type is Micron MT4HTF1664A. Have tried on a Xilinx Lab board and there it works (the difference is the that they use a smaller FPGA on that board). Thanks, NiklasArticle: 135776
On 15 Oct, 12:06, Leon <leon...@btinternet.com> wrote: > On 14 Oct, 22:26, James Harris <james.harri...@googlemail.com> wrote: ... > > Did you get any confirmation of booking? I too have booked for one of > > the London seminars but have nothing in writing to confirm that a > > place has been allocated. > > No, I didn't either. I had a problem with their payment system and > managed to make two bookings. I phoned them and they confirmed that > they'd received them and cancelled one of them for me. > > You could try phoning them if you aren't sure. OK, thanks. I have a place verbal confirmed. -- JamesArticle: 135777
Cross posted to comp.arch.fpga, as this is an intersting resource. Pinhas wrote: > http://bknpk.no-ip.biz/cpu_8051_ver/top.html > > # > > Stable Design: The design is translated from a VHDL dalton project > http://www.cs.ucr.edu/~dalton/i8051/i8051syn. > # > > Small Design: Consumes only 324 Flip-Flops: map report More map report details, from the link : Target Device : xc4vlx25 Number of Slice Flip Flops: 324 out of 21,504 1% Total Number 4 input LUTs: 2,423 out of 21,504 11% > # > > Fast Design: 50MHz for a xc4vlx25-10 XILINX device: timing report -jgArticle: 135778
On Tue, 14 Oct 2008 15:32:45 +0100, Paul Carpenter <paul@pcserviceselectronics.co.uk> wrote: >In article > <3d4b6f41-b742-405d-87bd-47e2fb75ac1d@8g2000hse.googlegroups.com>, >leon355@btinternet.com says... >> On 13 Oct, 20:42, Eric Smith <e...@brouhaha.com> wrote: >> > Bob wrote about XMOS: >> > >> > > They seem far too fixated on doing everything in software, things like >> > > ethernet where there is no point shoveling bytes in software if >> > > hardware can take care of it. >> > Leon wrote: >> > > They are supplying free libraries for all the usual peripheral >> > > functions. Doing stuff like that in software is much cheaper than >> > > using hardware, and easier in many ways. >> > >> > Been there, done that, and it's not cheaper or easier when you >> > consider the overall system cost impact, not just the "benefit" of >> > leaving out the hardware block. That was the path Scenix/Ubicom went >> > down, calling it "virtual peripherals", and it was not very >> > successful. Ubicom has since added hardware for Ethernet, USB, >> > etc. to their most recent parts. The reality is that a hardware >> > Ethernet MAC costs less than the total system cost impact of the >> > software alternative. >> > >> > Eric >> >> Not if you have four 400 MIPS cores on the chip, each with 64 bits of >> I/O, 64k of RAM, with 3.2 Gbit/s comms links between cores and 32 >> threads per core, with switching between threads in one clock. If the >> software is free, it is a very cost-effective solution, especially as >> the chips will be very cheap. > >The PC market solution to determinisity - > > "If in doubt put bigger processor(s) and > lots more memory to solve the 'problem'" > >Having seen how easily screwed even software UARTs can get, and >when something goes wrong all other activity is screwed. > >The PC example is dodgy CD inserted, nothing else can work until >the upto 30 seconds of lockout. Lots of other examples exist. > >This sort of software emulation of hardware ONLY is useful for >cheap and nasty commodity products that assume that unusability >is always solved by a reset (for some products that means host PC >AS WELL!). > >This means for the VAST majority of *my* applications it is useless. I fully agree with this. Software is flexible and easier to correct than hardware. Unfortunantely this has lead to the current thinking that we can ship the product with known issues, since "We can always fix it later". In most cases these fixes never happen. I would prefer more peripherals in hardware, not less. TCP/IP stack in hardware, USB stack in hardware etc. Something like IEEE-1394 is much more reliable than USB, since all the enumeration etc is handled by the hardware. With the right hardware support, which can be a few gates, software can often be made much simpler, more robust and faster. A simple thing like an atomic increment or decrement can be quite complex to implement in software. In hardware it is trivial. In my experience from porting code written for old hardware, to new hardware. Calculation tasks are much faster on modern hardware. Moving data around between buffers, and peripherals is only a little bit faster if at all. Simple things like hardware that provides the amount of space available in a FIFO in a register in stead of just a FIFO has space flag, can easily make the moving of data easily 5x faster. Regards Anton ErasmusArticle: 135779
uraniumore238@gmail.com wrote: > Hi Guys! > > Thanks for the help. So, I can insure myself that the FPGA is counting > as long as the FPGA is always driven by some input square wave and not > floting to some external squivering ? You can see the effect visually if you hold onto a scope probe tip For reliable counting, the FPGA should have a fast-edge signal, sufficently large. If this is a generic IP, then an external schmitt would be a good idea > How would I verify that it is > actually counting (despite the fact that the count value got to the > max) ? Any ideas ? Not clear what you are asking ? If you are looking for a signal presence detector, that is often a monostable and a led. Or, if you know the appx expected frequency range, you can feed an appropriate counter bit to an LEDArticle: 135780
On Oct 15, 7:51=A0am, "ALu...@web.de" <ALu...@web.de> wrote: > Hi newsgroup, > > can somebody tell me whether Altera uses a PLL to adjust the setup/ > hold timing > of their 32bit PCI master/target core ? > I am curious about it because other FPGA vendors do that. Doing so it > not always easy to find the correct phase of the PLL. > > Thank you for your opinion. > > Rgds > AluPin The Altera PCI core doesn't use a PLL. Since the PCI spec requires operation at clock rates from DC to 33 or 66 MHz, putting a PLL in there would most likely violate the spec.Article: 135781
Thanks But I have already checked it and seen it . It has as such nothing to do with CEP specifically. It is a C-HDL compiler which is used to automatically accelerate part of the computational demanding codes for FPGA. The financial feed handling part is in its increased flexibility to tweak and process and analyse the feed datas. If anybody can share some light on this discussion is most welcome. I will be grateful for any advices, hints and suggestions . SohamArticle: 135782
Dear all, I'm a newbie to FPGA's but have been playing with a demo board for the last couple of days. It's great fun, but I have some problems getting started with simulation. I use the free WebPack 10.1 from Xilinx and my target is a Spartan3. I have written a SPI transmitter in VHDL and tested successfully on my demo board. However, I want to learn how to do the simulation. The documentation seems a bit contradicting. All the tutorials describes how to use the waveform editor, but when I start that I says that it's not supported anymore and that I should use HDL based simulation. I then went to the menu project->new source->VHDL test bench. It then created a template for one of my modules. Now comes the big question... Where the heck do I then begin the simulation. I see no buttons or anything that indicates where to begin. Am I completely stupid or is there more to it? Thanks in advance! Regards JanArticle: 135783
Jim Granville wrote: >> >> Fast Design: 50MHz for a xc4vlx25-10 XILINX device: timing report > I don't want to nitpick. It looks like a nice and (maybe more important) little project. But on the web site I see the following performance figures: I8051_ALU: Critical Path Length (ns): 178 Maximum Clock Speed (MHz): 5.63 I have to admit that I'm a FPGA noob, but I think that part deserves some optimization. NilsArticle: 135784
On Thu, 16 Oct 2008 00:59:10 +0200, Jan <webpjat@future-designSLET.dk> wrote: >Dear all, >I then went to the menu project->new source->VHDL test bench. >It then created a template for one of my modules. So far so good... >Now comes the big >question... Where the heck do I then begin the simulation. I see no >buttons or anything that indicates where to begin. > >Am I completely stupid or is there more to it? There is more to it... the template doesn't actually define any tests; or even such basics as a clock signal. Within the architecture section of the template, you have to write VHDL code in the form of processes to set input signals to your module (such as clock, reset, as well as any data inputs. Then you can compile this, then run simulations and observe waveforms on its outputs. But best practice is also to read the outputs in the testbench, and compare those outputs with expected values, and report on any differences using Assert statements. Then the testbench is effectively self-checking, and you only need to inspect waveforms if something went wrong... The example projects ought to illustrate this - or google VHDL Testbench. - BrianArticle: 135785
Jan wrote:
> I use the free WebPack 10.1 from Xilinx and my target is a Spartan3.
You will need one the non-free oem modelsim software to do simulation:
http://www.xilinx.com/ise/optional_prod/mxe.htm
> All the tutorials describes how
> to use the waveform editor, but when I start that I says that it's not
> supported anymore and that I should use HDL based simulation.
That's good advice.
The waveform simulator was just a toy anyway.
Modelsim is a separate program
and has its own tutorials.
> I then went to the menu project->new source->VHDL test bench.
> It then created a template for one of my modules.
That template just hooks up the instance.
You have to write vhdl code to wiggle the inputs
and watch the outputs.
-- Mike Treseler
Article: 135786"Nils" <n.pipenbrinck@cubic.org> wrote in message news:6lnd94Fda23nU1@mid.uni-berlin.de... > Jim Granville wrote: >>> >>> Fast Design: 50MHz for a xc4vlx25-10 XILINX device: timing report >> > > I don't want to nitpick. It looks like a nice and (maybe more important) > little project. > > But on the web site I see the following performance figures: > > I8051_ALU: > > Critical Path Length (ns): 178 > Maximum Clock Speed (MHz): 5.63 > > I have to admit that I'm a FPGA noob, but I think that part deserves some > optimization. > > Nils Without reading TFA, I agree, I laughed where it says it's a small design because it only uses 324 FFs, and yet it uses 10 times as many LUTs! Cheers, Syms.Article: 135787
"Mike Treseler" <mtreseler@gmail.com> wrote in message news:48F68304.3000606@gmail.com... > You will need one the non-free oem modelsim software to do simulation: > http://www.xilinx.com/ise/optional_prod/mxe.htm There is a free version of ModelSim XE available. It's a bit limited, but fine for small projects.Article: 135788
Dear all, I'm trying to understand the RAM generated from the Xilinx (ISE 10.1) Core IP generator. I have generated a Distributed Dual-Port RAM and it has more ports than I expected. There is A and D port which I think is for read and writes. Then there is a SPO, DPO and DPRA which I'm not sure what does. I guess that the DPRA is address input (B side). But that is SPO and DPO then? Is both data output from the (B Side)? Thanks in advance! Regards JanArticle: 135789
Jan wrote: > Dear all, > > I'm trying to understand the RAM generated from the Xilinx (ISE 10.1) > Core IP generator. There are several parameters called "Non Registered" and "Registered". What does this mean? Thanks in advance! Regards JanArticle: 135790
The purpose of this post is to try to get a discussion going on various design tricks for severely limited devices like CPLDs. On that note I'll pose the following challenges to the group: Challenge 1 - Tetris in as few CPLDs as possible ------------------------------------------------ How would you design a Tetris game if you only had CPLDs available? How many CPLDs would you use and of what kind? Would you need any other kind of circuits to implement an efficient solution? (External SRAMs or EPROMs for example?) What kind of display would you use? (TV, Oscilloscope, Led matrix, etc?) What kind of input device would you use? (Plain buttons or perhaps a more advanced input device like a NES joypad?) I believe that this is a rather nice problem with many interesting optimization possibilities. Personally I have an almost finished solution based on the XC95 series. However, I will not tell you how many I need or the exact model number(s) that I'm using right now. I do have a rather nice architecture which I believe will be hard to improve on. I'll let you ponder this for a week or so before I post my idea for a solution. Challenge 2 - A digital watch with as few CPLDs as possible ----------------------------------------------------------- This is an easier problem which should require fewer or smaller CPLDs than the previous challenge. Requirements: * Time should be showed in HH:MM:SS format (preferably 24h format) * It should be possible to set an alarm (HH:MM precision is good enough) * Stop watch functionality in MM:SS:T (That is, up to 59 minutes, 59 seconds and 9 tenths of a second.) * There should be a user interface of some kind (it should be possible to change the time that is) * The time, alarm, and stop watch functionality shall work independently. (You don't want your watch to stop working just because you are setting your alarm or using the stop watch.) What kind of display would you use here? (7 segment LEDs? LCD?, etc?) What kind of input? (Plain buttons or something different?) What clock frequency do you need? This is a rather nice problem which will allow you to think about the best way to do resource sharing in a CPLD. As a baseline, the students I have supervised who do this kind of project end up with about 3 or 4 CPLDs. (Either XC9572 or XC95108.) They usually don't bother with any kind of resource sharing though... Personally, I have a relatively small solution to this, but there are still a few tricks I haven't used. In my solution I'm using a 7 segment LED driver circuit with built in NBCD decoder (the 9368), so if you want to compare your solution to mine you might want to output NBCD coded numbers out of your CPLD. I'll let you ponder this problem for a few days or so as well before doing a small writeup on my solution. /AndreasArticle: 135791
On 2008-10-16, Herbert Kleebauer <klee@unibwm.de> wrote:
> Andreas Ehliar wrote:
>>
>> The purpose of this post is to try to get a discussion going
>> on various design tricks for severely limited devices like CPLDs.
>> On that note I'll pose the following challenges to the group:
>>
>> Challenge 1 - Tetris in as few CPLDs as possible
>
>> Challenge 2 - A digital watch with as few CPLDs as possible
>
> Put a simple soft core CPU in a xc95 and add some ROM/RAM, then
> a single CPLD should be enough.
That is probably the easiest solution. A colleague and I have
investigated this approach a little bit to try to figure out the
optimal architecture. The goal would be to have both sound output
and tile based graphics in this case. We were aiming for a XC9572,
but we gave up on it since programming would be extremely cumbersome
as both audio and video would require cycle accurate code.
Some of the tricks we learned while doing this was to move around
our address register and the program counter so that one of them
always addressed the memory.
At first we considered the following architecture:
+---+
PC --->| |
|MUX|---> Address to memory
AR --->| |
+---+
However, if we do it like this instead:
+-------------------------------+
| |
| +--+ +--+ |
| |PC| +-------+ |AR| |
+->| |--->| Adder |--->| |----+---> Address to memory
|> | +-------+ |> |
+--+ +--+
The adder adds either 1 or 0. If we always exchange PC and
AR two times during the execution of one instruction we will
both be able to address memory through the address register and
fetch the instruction. We will also get the operation AR++ for
free. But most importantly: As we no longer have the mux, we save
these macrocells for other uses. This is quite important since the 9572
only has 72 macrocells...
However, what about if you would like to avoid an SRAM and EPROM,
what kind of techniques would you use in that case?
/Andreas
Article: 135792On 2008-10-16, Frank Buss <fb@frank-buss.de> wrote: > Andreas Ehliar wrote: > >> How would you design a Tetris game if you only had CPLDs >> available? How many CPLDs would you use and of what kind? > > The question doesn't make sense. I would use a EPM2210/G with 2,210 LEs and > could install Nios on it, so all I need is one CPLD. My intention was to challenge the group to use as few CPLDs and as small CPLDs as possible. Although I admit that you will be probably be finished with your solution before I'm even finished with trying to figure out the architecture of my solution :) /AndreasArticle: 135793
Jan wrote: > Dear all, > > I'm trying to understand the RAM generated from the Xilinx (ISE 10.1) > Core IP generator. > I have generated a Distributed Dual-Port RAM and it has more ports than > I expected. > > There is A and D port which I think is for read and writes. > Then there is a SPO, DPO and DPRA which I'm not sure what does. > I guess that the DPRA is address input (B side). But that is SPO and DPO > then? Is both data output from the (B Side)? > > Thanks in advance! > > Regards > Jan There are two coupled LUTs for each dual-port distributed memory. The normal address (A input) is used for the write (D input) along with the control (WE). The Single Port Output (SPO output) is the same as you'd have with distributed single port memories where the write address also controls the single port read so you can perform a read-modify-write with an async read to the clock edge where the data is taken in. The other LUT has a separate Dual Port Read Address (DPRA input) which gives you an async read on the Dual Port Output port (DPO output). The LUTs are normally only registered in the sense that a write moves the data into the memory array and can then be accessed asynchronously. The option in the Core IP Generator is probably to add the registers that are directly adjacent to the SPO and DPO LUT outputs within the slice to be used allowing a very fast clock-to-output time without waiting for the address propagation for the async lookup. The registered operation is another clock of pipeline and should be treated conceptually just like adding the registers manually yourself. The distributed memories and the shift register mode in these Xilinx devices are very important features of the FPGA in my opinion. While one can design without these memories, the resource savings where they are used can be pretty intense. - John_HArticle: 135794
Hi Jan, > I then went to the menu project->new source->VHDL test bench. > It then created a template for one of my modules. Now comes the big > question... Where the heck do I then begin the simulation. I see no > buttons or anything that indicates where to begin. On top of the Project(Sources) window inside the ISE Project Navigator is a small Selection Box that reads: Sources for: "Implementation" by default. If you click on the right triangle the available options drop down. One of them is "Behavioral Simulation". Use that one to see and edit your Testbench(template) and also you will recognize that the processes window changes and gives access to the installed simulator tools (either ISE simulator or Modelsim Starter) Have a nice simulation EilertArticle: 135795
"Nils" <n.pipenbrinck@cubic.org> wrote in message news:6lnd94Fda23nU1@mid.uni-berlin.de... > Jim Granville wrote: > >> > >> Fast Design: 50MHz for a xc4vlx25-10 XILINX device: timing report > > > > I don't want to nitpick. It looks like a nice and (maybe more important) > little project. > > But on the web site I see the following performance figures: > > I8051_ALU: > > Critical Path Length (ns): 178 > Maximum Clock Speed (MHz): 5.63 > > I have to admit that I'm a FPGA noob, but I think that part deserves > some optimization. And some work too.... Quote: Limitations: This implementation is not cycle/timing compatible. Interrupt handling is not currently implemented. Peripheral devices are not currently implemented. MeindertArticle: 135796
On 16 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91=D7=A8, 08:27, "Meindert Sprang" <m...@NOJUNKcustomORSPAMware.nl> wrote: > "Nils" <n.pipenbri...@cubic.org> wrote in message > > news:6lnd94Fda23nU1@mid.uni-berlin.de... > > > > > Jim Granville wrote: > > > >> Fast Design: 50MHz for a xc4vlx25-10 XILINX device: timing report > > > I don't want to nitpick. It looks like a nice and (maybe more important= ) > > little project. > > > But on the web site I see the following performance figures: > > > I8051_ALU: > > > =C2=A0 =C2=A0Critical Path Length (ns): 178 > > =C2=A0 =C2=A0Maximum Clock Speed (MHz): 5.63 > > > I have to admit that I'm a FPGA noob, but I think that part deserves > > some optimization. > > And some work too.... > > Quote: > Limitations: > =C2=A0 This implementation is not cycle/timing compatible. > =C2=A0 Interrupt handling is not currently implemented. > =C2=A0 Peripheral devices are not currently implemented. > > Meindert As far as I remeber this is a multicycle path. But I'll double check.Article: 135797
On Oct 15, 8:04=A0pm, Barry <barry...@gmail.com> wrote: > On Oct 15, 2:30=A0am, chrisde...@gmail.com wrote: > > > > > Hi, > > > can someone who has used Xilinx's MIG DDR2 controller help? > > > I am trying to simulate the DDR2 controller with memory > > MT4HTF3264HY-53ED3 memory model generated by MIG 2.0 (Xilinx ISE 10.1 > > SP3). I had set the burst length to 8. I need to have good knowledge > > of the timing of the controller as I need to optimize its usage for an > > embedded system. > > > In the RTL simulation, I write to DDR2 RAM model at 133 MHz clock > > frequency from memory locations 0x0 to 0x400 in 1 burst via the > > application interface, and then observe the timing on the DDR2 bus. > > The DDR2 model is the one that I generated from MIG2.0. > > > Here is what I noticed: > > 1) a precharge occured after writing to memory location 0x260. this is > > followed by a refresh and activate. > > > To my understanding, a precharge and subsequent activate should happen > > only if i am accessing an address greater than 1024 or 0x3FF, since > > the column width of the RAM is 10 bits. Morever, I am doing a write > > burst to sequential addresses 0 to 0x400. > > > 2) TRAS which is delay between active and precharge is supposed to be > > 40 ns. but from the above point, this does not seem to be much longer. > > > 3) Also, i thought 7800 us is the interval between 2 refresh. how come > > it refreshes so much earlier? isn't this very inefficient? > > > did i miss out anything? kindly help and advice. > > > thanks in advance, > > Chris > > 3) The average refresh interval is 7.8 usec. Hi Chris, Can you clarify few questions: 1. Are you using Virtex4 controller or Virtex5 controller? 2. Did you generate the design from MIG at 133MHz or did you change the frequency after generating the design? Here are few answers: 1. Precharge command is occurred not due to address and it appeared due to Auto Refresh Command. 2. Whats the time did you observe between Active and Precharge command. Whether are you getting any violation errors in simulations? 3. Can you observe once in simulations whats the time interval between 2 auto refresh commands? Regards, PraveenArticle: 135798
On Oct 15, 8:13=A0pm, niklas_mo...@hotmail.com wrote: > On Oct 14, 11:55=A0pm, PatC <p...@REMOVETHISpatocarr.com> wrote: > > > > > niklas_mo...@hotmail.com wrote: > > > Hi. > > > > I have a design with a Virtex 5 and a DDR2 memory. > > > It seems like there is some problem when I read from the DDR2 memory > > > and I was hoping that someone here might recognize the problem. > > > > Here is what happens. > > > My base address for the memory is 0x88000000 > > > > I write following bytes (byte write) 0x11 to 0x88000000, 0x22 to > > > 0x88000001, 0x33 to 0x88000002, 0x44 to 0x88000003. > > > > When I read from the memory it will look like (32 bits format): > > > 0x88000000 =A0 =A0 =A0 =A011000000 > > > 0x88000004 =A0 =A0 =A0 =A000000000 > > > 0x88000008 =A0 =A0 =A0 =A000000000 > > > 0x8800000C =A0 =A0 =A0 =A000000000 > > > 0x88000010 =A0 =A0 =A0 =A000223344 > > > > But sometimes it seems to work and then I try to reload the bit-file > > > and then I get the same problem again. > > > What I notice is that when it works I write i.e 0x11223344 and will > > > read back > > > 0x88000000 =A0 =A0 =A0 =A011223344 > > > 0x88000004 =A0 =A0 =A0 =A000000000 > > > 0x88000008 =A0 =A0 =A0 =A000000000 > > > 0x8800000C =A0 =A0 =A0 =A000000000 > > > 0x88000010 =A0 =A0 =A0 =A000000000 > > > > If I reload the bit-file I will read back: > > > 0x88000000 =A0 =A0 =A0 =A011000000 > > > 0x88000004 =A0 =A0 =A0 =A000000000 > > > 0x88000008 =A0 =A0 =A0 =A000000000 > > > 0x8800000C =A0 =A0 =A0 =A000000000 > > > 0x88000010 =A0 =A0 =A0 =A000223344 > > > > So my conclusion is that the write part always seems to work, but it > > > the read part that doesn't work. > > > Could the be a problem with the IDELAYCTRL that is not calibrated? > > > > Thanks, > > > Niklas > > > Hi Niklas, > > > =A0 =A0Your question is quite broad and lacks details. > > > - Which controller are you using? MIG-generated, your own, etc. > > > - What SDRAM type is it? 4-burst length? > > > - When you say base address, are you using an embedded processor? > > > - Does it work in simulation? *g* > > > Cheers, > > -Pat > > Hi Pat. > > Yes, I'm using a Microblaze (EDK) and the controller is MPMC 3.0 and > the also used the MIG-generator. > The burst length is 8 and the memory type is Micron MT4HTF1664A. > > Have tried on a Xilinx Lab board and there it works (the difference is > the that they use a smaller FPGA on that board). > > Thanks, > Niklas Hi Niklas, I have few questions to be clarified: 1. You mentioned that you are using Mircon MT4HTF1664A. So you are testing the UDIMM design, but you mentioned only 32 bits as bus, are you looking at 64-bits or not? 2. Whether calibration is getting completed properly (PHY_INIT_DONE is asserted)? 3. Which Xilinx Lab board did you verify? 4. At what frequency are you verifying the design? 5. UDIMM performance will vary based on Load of UDIMM. UDIMM loading issues mentioned in XAPP858 as follows: Chip Select Timing in High Loading Situations Timing on the chip select signal becomes critical on heavily loaded DIMMs because the chip select signal remains a =931T=94 signal, even when 2T timing is enabled. In some cases, the loading may be so large, that the chip select cannot meet the setup time requirements for the next clock edge. In this case, the chip select signal can be asserted one-quarter or one-half clock cycle earlier than is normally done in the DDR2 interface design =96 by default, CLK0 is used to clock the chip select output flop; instead, CLK270 (inverted version of CLK90), or CLK180 (inverted version of CLK0) may be used to clock the chip select output flop. The DDR2 design must be manually modified to support this. The user must take care that the chip select is not advanced so much that a hold time violation now occurs. Regards, PraveenArticle: 135799
On 2008-10-16, Jim Granville <no.spam@designtools.maps.co.nz> wrote: > No mention of leading zero suppression ? I haven't really thought about it, but that would make a nice addition :) >> What kind of display would you use here? (7 segment LEDs? LCD?, etc?) > > MUX'd or Non MUX'd ? > LCDs need a XOR backplane, and they also have MUX choices too. I didn't use a mux'd solution, but as you point out further down I'm cheating somewhat with my choice of LED drivers. MUX'd would probably be better if using traditional driver circuits like the ULN2003. > 50Hz, 60Hz and 32.768KHz are the common ones.... 50 Hz and 60 Hz are quite hard if you want to do some kind of resource sharing. If you use 32768 Hz it is much easier to move things around to only one arithmetic block. > You could get them to code direct 7 segment counters, for a non-mux > display. Nice to show there are non Bin/bcd counters possible too... I haven't thought about that at all, that is a very interesting counter idea. It is probably not going to be useful in many cases but you never know when something similar will save your day :) >> Personally, I have a relatively small solution to this, but there are still >> a few tricks I haven't used. In my solution I'm using a 7 segment LED driver >> circuit with built in NBCD decoder (the 9368), so if you want to compare >> your solution to mine you might want to output NBCD coded numbers out of your >> CPLD. > > Surely the 9368 should be part of the CPLD ? Yes. But I had to use some sort of LED driving circuit, and we had lots of 9368 in the lab :) Perhaps I'll try to update my solution to use a more traditional LED driver instead. Unfortunately that is probably going to mean that I have to use a larger CPLD as the current version is filled to the limit. On the other hand, that would also allow me to fit a clock prescaler into the CPLD to avoid the very non-standard frequency the current solution needs :) But I agree that I'm cheating a little bit here. /Andreas
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