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
Hey everyone, I have been struggling to use the MIG to generate a memory interface to the DDR2 device. First some background info: I am using the Xilinx=AE Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 with MIG v2.3. I have created the MIG from GUI and played around with it. I also edited the UCF file (just changed the locations basically, did not mess around with timings). I cannot do any simulation because I am using Windows 7 and apparently, simulation doesn't work (or maybe some other problem). Anyway, the thing is I can download the code to the device and I can see all the signals go up and down in correct times. (like init_done, user_cmd_ack, user_data_valid etc.) Then I try to write some data to the memory, I can see user_cmd_ack go high, then I assert burst_done, then I can see user_cmd_ack go low. (which means write is succesful, right?) However, whenever I try to 'read' from the memory, I always get x"00000000" no matter what the address is. What can be wrong with it? Thanks for the help.Article: 147401
On Apr 26, 9:17=A0am, Berk <berkgura...@gmail.com> wrote: > Hey everyone, > > I have been struggling to use the MIG to generate a memory interface > to the DDR2 device. First some background info: I am using the Xilinx=AE > Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 with > MIG v2.3. > > I have created the MIG from GUI and played around with it. I also > edited the UCF file (just changed the locations basically, did not > mess around with timings). I cannot do any simulation because I am > using Windows 7 and apparently, simulation doesn't work (or maybe some > other problem). > > Anyway, the thing is I can download the code to the device and I can > see all the signals go up and down in correct times. (like init_done, > user_cmd_ack, user_data_valid etc.) Then I try to write some data to > the memory, I can see user_cmd_ack go high, then I assert burst_done, > then I can see user_cmd_ack go low. (which means write is succesful, > right?) However, whenever I try to 'read' from the memory, I always > get x"00000000" no matter what the address is. What can be wrong with > it? > > Thanks for the help. DDR2 timing is not easy to meet in the Spartan parts, so you really can't just muck around with the pinouts. If you changed the location of any memory pins you need to re-run the MIG configuration GUI and use the option to "Verify UCF". This tells MIG to generate new timing and directed routing constraints based on the pin locations from your actual design. By the way I thought that the Starter boards come with a pre-built version of the MIG design. Have you looked into that? Regards, GaborArticle: 147402
I am using data2mem to generate some .mem simulation files. My address for
memory starts at 0x86000000 and if I dump the elf file I can see that.
However when I run data2mem the .mem file starts at address 0x00000000. The
command I am using is
data2mem -bd memory_init.bmm -bd test.elf -bx -u -i
and my bmm looks like
ADDRESS_SPACE ddr2_sdram MEMORY [0x86000000:0xA5FFFFFF]
BUS_BLOCK
system_tb/ddr2_0 [15:0] OUTPUT = ddr2_0.mem;
END_BUS_BLOCK;
END_ADDRESS_SPACE;
I cant see anything wrong unless I am missing something with data2mem.
Thanks
Jon
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 147403On 26 Nisan, 16:39, Gabor <ga...@alacron.com> wrote: > On Apr 26, 9:17=A0am, Berk <berkgura...@gmail.com> wrote: > > > > > > > Hey everyone, > > > I have been struggling to use the MIG to generate a memory interface > > to the DDR2 device. First some background info: I am using the Xilinx= =AE > > Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 wi= th > > MIG v2.3. > > > I have created the MIG from GUI and played around with it. I also > > edited the UCF file (just changed the locations basically, did not > > mess around with timings). I cannot do any simulation because I am > > using Windows 7 and apparently, simulation doesn't work (or maybe some > > other problem). > > > Anyway, the thing is I can download the code to the device and I can > > see all the signals go up and down in correct times. (like init_done, > > user_cmd_ack, user_data_valid etc.) Then I try to write some data to > > the memory, I can see user_cmd_ack go high, then I assert burst_done, > > then I can see user_cmd_ack go low. (which means write is succesful, > > right?) However, whenever I try to 'read' from the memory, I always > > get x"00000000" no matter what the address is. What can be wrong with > > it? > > > Thanks for the help. Hello, > DDR2 timing is not easy to meet in the Spartan parts, so you really > can't just muck around with the pinouts. =A0If you changed the location > of any memory pins you need to re-run the MIG configuration GUI and > use the option to "Verify UCF". =A0This tells MIG to generate new > timing and directed routing constraints based on the pin locations > from your actual design. Actually, I did just that. First, I let MIG create a 'wrong' UCF file. Then I changed the pinouts correctly. Then I selected "Update Design" and pointed it to my newly edited UCF file. Then, it changed the pinouts and timings. But there is no change in the output. By the way I am changing the UCF file under the user_design folder. I think this is correct. How can I verify if I'm having a UCF error or something else? > By the way I thought that the Starter boards come with a pre-built > version of the MIG design. =A0Have you looked into that? > Regards, > Gabor Yeah, I did that but my Starter board is not supported. Thanks a lot.Article: 147404
On Apr 25, 10:57=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > As to the XOR, I don't have code to share; I developed it a while ago > for some asynchronous stuff and it applies well to multi-port writes. The idea is definitely floating around. Multiple people have independently suggested it to me after seeing the LVT approach. It's definitely an interesting approach. > As I try to put together a clearer explanation, I find I may have been > wrong about the memory count for the XOR approach such that the LVT > would use fewer. =A0I still believe the LVT approach requires M*N > BlockRAMs for an M-write, N-read multi-port memory plus the LVT; I'm > having trouble remembering why I thought the "+1" was needed. =A0The XOR > approach appears to need M*(M-1+N) memories. > > If you have 3 write ports and 4 read ports, you'll need 3 sets of *6* > memories. <snip> Yep, you are right. The number of BlockRAMs required is M*N, plus the LVT (which uses no Block RAMs). Thanks for the explanation of the XOR design. You're the first to do so. It makes a lot of sense, except I don't see why you need the extra M-1 memories on the read side? > The LVT needs a memory for each write port but requires multiples of > them to accommodate every read port in case the multiple reads for any > one cycle are all from the same write bank for the most recently > updated value. *Exactly* > Depending on the complexity of the LVT, the number of write ports, and > the allowable latencies, the LVT could be a more effective approach. It tends to be, given the research so far, but if an extra cycle of latency (to do the reads to get the decoding data) is acceptable for a design, the XOR approach could be very useful. The LVT does add delay, but it's still faster than the alternatives I explored for an arbitrary number of ports (for small numbers, pure multipumping works better).Article: 147405
On Apr 25, 12:03=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > 5. Your final conclusion about write-and-read schedule is not right. > When people is using your method, they are still facing write-and-read > scheduling. > For example, there is a wait list pool to receive write and read > requests, and the pool can hold 200 write requests and 200 read > requests. <snip> There is no read/write scheduling problem *within a cycle*. If you have more pending reads/writes than there are ports, then of course there will always be a scheduling problem, but that's a different problem more akin to that solved by reorder buffers in a dynamically scheduled CPU. As for simultaneous reads and writes to the same address, the behaviour is a function of how the underlying Block RAMs are configured. For a read and a write to the same address, you can specify that the read port returns either the old value or the current one being written. This doesn't affect the rest of the LVT-based design. In the case of two simultaneous *writes* to the same address, the default behaviour is like most any other multiported memory: undefined. However, there is no *physical* conflict in the banks of Block RAMs, but only in the LVT. So you can go ahead and store both writes and decide what to store in the LVT as part of your conflict resolution logic (eg: lower port number has priority, etc...).Article: 147406
Challenge : 18*18 data with one data vector unsigned and the other
signed. FPGA DSP block actually
has separate signals to set the sign of each
operand.
If the operands are the full data width of the
DPS block inputs it is not possible to
"sign extend" the unsingned operand.
Anyone been able to achieve this task?
Best Regards
David Greig
Article: 147407>Could you try to introduce an error in the package declaration, >just to see that the compiler/analyzer is actually looking >at the file you think its looking at?!? >-- Pontus > I removed a ";" at the end of a constant declaration in the package. The "Compile Only" process that I ran on my entity found the error in the package. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147408
On 26 Apr., 17:20, dgreig <dgr...@ieee.org> wrote: > Challenge : 18*18 data with one data =A0vector unsigned and the other > signed. FPGA DSP block actually > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has separate signals to se= t the sign of each > operand. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If the operands are the fu= ll data width of the > DPS block inputs it is not possible to > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"sign extend" the unsingne= d operand. > > Anyone been able to achieve this task? Signed Mutlipliers usually are unsigned mutlipliers of one bit less with extra logic to get the sign right. Therefore you should think of Xilinx DSP block as a 17x17 multiplier. Use an extra conditional adder after the multiplier to get 18x18 in your case. KoljaArticle: 147409
On Apr 26, 10:10=A0am, Berk <berkgura...@gmail.com> wrote: > On 26 Nisan, 16:39, Gabor <ga...@alacron.com> wrote: > > > > > On Apr 26, 9:17=A0am, Berk <berkgura...@gmail.com> wrote: > > > > Hey everyone, > > > > I have been struggling to use the MIG to generate a memory interface > > > to the DDR2 device. First some background info: I am using the Xilinx= =AE > > > Spartan=AE-3A DSP XtremeDSP=99 Starter Platform. I am using ISE 10.1 = with > > > MIG v2.3. > > > > I have created the MIG from GUI and played around with it. I also > > > edited the UCF file (just changed the locations basically, did not > > > mess around with timings). I cannot do any simulation because I am > > > using Windows 7 and apparently, simulation doesn't work (or maybe som= e > > > other problem). > > > > Anyway, the thing is I can download the code to the device and I can > > > see all the signals go up and down in correct times. (like init_done, > > > user_cmd_ack, user_data_valid etc.) Then I try to write some data to > > > the memory, I can see user_cmd_ack go high, then I assert burst_done, > > > then I can see user_cmd_ack go low. (which means write is succesful, > > > right?) However, whenever I try to 'read' from the memory, I always > > > get x"00000000" no matter what the address is. What can be wrong with > > > it? > > > > Thanks for the help. > > Hello, > > > DDR2 timing is not easy to meet in the Spartan parts, so you really > > can't just muck around with the pinouts. =A0If you changed the location > > of any memory pins you need to re-run the MIG configuration GUI and > > use the option to "Verify UCF". =A0This tells MIG to generate new > > timing and directed routing constraints based on the pin locations > > from your actual design. > > Actually, I did just that. First, I let MIG create a 'wrong' UCF file. > Then I changed the pinouts correctly. Then I > selected "Update Design" and pointed it to my newly edited UCF file. > Then, it changed the pinouts and timings. > But there is no change in the output. By the way I am changing the UCF > file under the user_design folder. I think > this is correct. How can I verify if I'm having a UCF error or > something else? > > > By the way I thought that the Starter boards come with a pre-built > > version of the MIG design. =A0Have you looked into that? > > Regards, > > Gabor > > Yeah, I did that but my Starter board is not supported. > > Thanks a lot. Well the obvious thing you can do is check the pad report to make sure the correct pinout is in use. You can also go into the FPGA editor and check that your MIG-related pins have all the appropriate registers in the IOB tiles. Then there's the obvious stuff like checking your clock and reset inputs to be sure they're hooked up properly. I've often started going down a head-scratching path with DDR designs only to find that the active-low reset input was connected to an active high reset signal, or that the DCM was being reset be a register clocked on its own output (this doesn't work with DCM's because the CLK0 output shuts off when reset is active). HTH, GaborArticle: 147410
On Apr 26, 6:10=A0pm, Kolja Sulimma <ksuli...@googlemail.com> wrote: > On 26 Apr., 17:20, dgreig <dgr...@ieee.org> wrote: > > > Challenge : 18*18 data with one data =A0vector unsigned and the other > > signed. FPGA DSP block actually > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has separate signals to = set the sign of each > > operand. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If the operands are the = full data width of the > > DPS block inputs it is not possible to > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"sign extend" the unsing= ned operand. > > > Anyone been able to achieve this task? > > Signed Mutlipliers usually are unsigned mutlipliers of one bit less > with extra logic to get the sign right. > Therefore you should think of Xilinx DSP block as a 17x17 multiplier. > > Use an extra conditional adder after the multiplier to get 18x18 in > your case. > > Kolja Okay, for Altera there are actually "signa" and "signb" controls for inputs a and b respectively, so it is physically possible to have signal a_i : unsigned(17 downto 0); signal b_i : signed(17 downto 0); signal axb_o : signed(35 downto 0); Suppose the application is DSP on physical data that happens to be unsigned by nature with the other operand signed - if the data consists of 18 "good" bits and the application requires all 18 then it is undesirable not to utilise all of the resources. Perhaps suppose it is image sensor data and feature detection DSP. Data is naturally unsigned and the other operand mostly signed. In this case say 9*9 and 2D DSP. Losing a bit off the image data is certainly undesirable and the alternative cosly or limits function if 18*18 multipliers have to be inferred as a kludge. Best Regards DGArticle: 147411
dgreig <dgreig@ieee.org> wrote: > Challenge : 18*18 data with one data vector unsigned and the other > signed. FPGA DSP block actually has separate signals to set the > sign of each operand. > If the operands are the full data width of the DPS block inputs > it is not possible to "sign extend" the unsingned operand. > Anyone been able to achieve this task? For twos complement multiply, you subtract instead of add if the sign bit is one. So all the signed/unsigned control input does is to turn an adder into a subtractor. Signed or unsigned, an N by N bit product fits into 2N bits. -- glenArticle: 147412
"dgreig" <dgreig@ieee.org> wrote in message news:8c1c9a60-fef0-4aa2-aa00-54761db33af0@s41g2000vba.googlegroups.com... > Perhaps suppose it is image sensor data and feature detection DSP. > Data is naturally unsigned and the other operand mostly signed. In > this case say 9*9 and 2D DSP. Losing a bit off the image data is > certainly undesirable and the alternative cosly or limits function if > 18*18 multipliers have to be inferred as a kludge. One trick I've used is to convert the unsigned data to signed at the filter input, then back to unsigned on the output. Most of the video filters I built in the late 70s worked that way. Once you've wrapped your brain round mid-grey being 0, it's easy to deal with.Article: 147413
Hello,
I'm writing a boot loader to start Linux on the PowerPC440 (Virtex5FXT).
At first the program copies the kernel into the RAM at address
0x00400000 and afterwards it boots Linux with the following lines:
#define LINUX_START_ADDRESS 0x004002b4
int main()
{
void (*linux)();
linux = (void*) LINUX_START_ADDRESS;
... // here is the code which copies the kernel into ram
(*linux)();
}
With the following steps, booting works fine:
(1). comment out the line (*linux)();
(2). start the program
(3). start xmd and enter "rst -processor"
(4). set the program counter: "rwr pc 0x004002b4"
(5). enter "con"
What does not work:
Starting Linux directly within the program with the last line.
All I can see is the following and thats all.
zImage starting: loaded at 0x00400000 (sp: 0x00569fb0)
Allocating 0x2efa98 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x0056837e)...done 0x2d2270 bytes
Linux/PowerPC load: console=ttyUL0 root=/dev/mmcblk0p1 rootdelay=5
Finalizing device tree... flat tree at 0x576300
So the question is: What do I have to do to boot Linux from within the
program?
Best Regards
Martin Brückner
Article: 147414
Hello,
I'm running ISE 9.2.03i on a design for Spartan 3E (3s250e-4tq144).
For whoever wishes to skip the long description below, the idea is
simple: The tools should not agree to place pins with conflicting IO
standards, such as LVTTL and LVCMOS25, on the same bank. And suddenly
I caught the tools not noticing this. This clearly looks like a bug,
among others because slight tweaks with the source Verilog makes the
tools reject the conflict, as they should.
My question is if someone has had similar experience, and if there's a
way to be sure that the tools indeed detect collisions when they
occur.
And now to the long story, for those who want the details. A lot of
details, which I doubt if they're relevant. But anyhow.
Recently, I've been doing this pin placement back-and-forth with the
board designer. Since the logic isn't written yet, I've written dummy
logic for the I/O pins. So each time the board designer wants a
change, I make the change in the UCF file, run an implementation, and
see if there are complaints. If they do, I get an error like the
example at the bottom of this post (in case of an IO standard
violation), or errors about problems in clock routing. For a few
years, this has been my method to quickly approve pinouts, until this
method failed recently.
What I found out, is that the tools agreed to place LVTTL pins and
LVCMOS25 on the same bank, if they were defined as inouts (that is,
bidirectional). I verified this by looking at the pad report and with
FPGA editor. If I made both pins outputs, the tools refused, as they
should. Other irrelevant tweaks with the code (such as commenting out
irrelevant parts) also woke up the sleeping guard.
The method I use for checking is instantiating a module like at the
bottom of this message. The IOSTANDARD parameter is set at
instantiation to the desired standard. The module generates DDR flip-
flops for both input and output, so if placement and routing succeeds,
I know that the certain pin's placement is OK, and that IOB registers
with the given clock can be packed. Or so I thought.
I have, of course, other modules for input-only, output-only,
nonclocked IOs, differential IOs and such.
This looks like a bug in the tools. Unfortunately, I failed to make a
simple example which demonstrates the bug. It looks like the tools are
OK most of the time, but it's disturbing that they may fail on me even
once (and make me approve a faulty board design).
So has anyone encountered a similar problem?
Thanks in advance,
Eli
---------------------------
Example of error from placer.
============================
ERROR:Place:864 - Incompatible IOB's are locked to the same bank 3
Conflicting IO Standards are:
IO Standard 1: Name = LVCMOS25, VREF = NR, VCCO = 2.50, TERM = NONE
List of locked IOB's:
data<0>
data<1>
IO Standard 2: Name = LVTTL, VREF = NR, VCCO = 3.30, TERM = NONE
List of locked IOB's:
testpoints<1>
testpoints<3>
The test module
===============
module testiob #(parameter IOSTANDARD = "LVTTL")
(inout pin,
input clk);
wire in, out, T;
wire in_fall, in_rise;
reg in_fall_d, in_rise_d;
always @(posedge clk)
begin
in_fall_d <= in_fall;
in_rise_d <= in_rise;
end
// This is completely useless setting. It just puts the IOB in
place.
// It may drive the lines crazy if used for real
IOBUF #(.IOSTANDARD(IOSTANDARD)) iobuf
(.IO(pin), .I(out), .O(in), .T(T));
ODDR2 #(.SRTYPE("ASYNC")) out_ddr
(.Q (out),
.C0 (clk),
.C1 (!clk),
.CE (1'b1),
.R (1'b0),
.D0 (in_rise_d),
.D1 (in_fall_d),
.S (1'b0));
ODDR2 #(.SRTYPE("ASYNC")) T_ddr
(.Q (T),
.C0 (clk),
.C1 (!clk),
.CE (1'b1),
.R (1'b0),
.D0 (in_rise_d),
.D1 (in_fall_d),
.S (1'b0));
IDDR2 #(.SRTYPE("ASYNC")) in_ddr
(
.Q0 (in_rise),
.Q1 (in_fall),
.C0 (clk),
.C1 (!clk),
.CE (1'b1),
.D (in),
.R (1'b0),
.S (1'b0));
endmodule
Article: 147415On Apr 25, 11:54=A0pm, David Brown <da...@westcontrol.removethisbit.com> wrote: > On 23/04/2010 21:39, Rich Webb wrote: > > > > > > > On Fri, 23 Apr 2010 10:19:07 -0700 (PDT), Wastrel > > <stephensdigi...@gmail.com> =A0wrote: > > >> On Apr 21, 1:08 pm, Jon Beniston<j...@beniston.com> =A0wrote: > >>> It's running ok for me on Windows 7 64-bit. > > >>> What particular part of the software are you having problems with? > > >>> Jon > > >> Well it installs alright, but Altium Designer 6 can't find it - > >> whereas it did on my XP box. One problem is that Windows 7 likes to > >> put 32 bit legacy programs under Program FIles(x86), but Quartus won't > >> install there because it can't handle spaces or special characters in > >> it's filenames. > > > Tell it to use the 8.3 name for the directory (one way of seeing this i= s > > to do a "dir /X" from a command prompt). For the directory above, the > > name would be "c:\progra~2\". > > Alternatively, avoid "Program Files" or "Program Files (x86)" like the > plague - these are seriously stupid path names MS has chosen. > > When installing almost any new software, you have a free choice of the > installation path - if you think you might ever want to refer to the > program or its files by path name (such as the command line), use > something like "c:\Progs\" as the base instead of "c:\Program Files". > > I have no idea whether this will help you here or not, but it will avoid > the awkward installation path.- Hide quoted text - > > - Show quoted text - Well Altium support got back to me and said basically the same thing you guys are: "It works OK for me" They told me to verify that the system environment variable "QUARTUS_ROOTDIR" pointed to the right folder - it did. I upgraded the OS to Windows 7 Professional from "Home Premium" still no joy. When I run Windows' compatibility troubleshooter it comes back with "Incompatible Application" so there's something funky going on. I'm wasting way to much time on this stupid problem, but it's not so easy finding an XP box anymore so I'm not just sure what my next move is.Article: 147416
On Apr 26, 1:59=A0pm, Eli <eli.billa...@gmail.com> wrote:
> Hello,
>
> I'm running ISE 9.2.03i on a design for Spartan 3E (3s250e-4tq144).
>
> For whoever wishes to skip the long description below, the idea is
> simple: The tools should not agree to place pins with conflicting IO
> standards, such as LVTTL and LVCMOS25, on the same bank. And suddenly
> I caught the tools not noticing this. This clearly looks like a bug,
> among others because slight tweaks with the source Verilog makes the
> tools reject the conflict, as they should.
>
> My question is if someone has had similar experience, and if there's a
> way to be sure that the tools indeed detect collisions when they
> occur.
>
> And now to the long story, for those who want the details. A lot of
> details, which I doubt if they're relevant. But anyhow.
>
> Recently, I've been doing this pin placement back-and-forth with the
> board designer. Since the logic isn't written yet, I've written dummy
> logic for the I/O pins. So each time the board designer wants a
> change, I make the change in the UCF file, run an implementation, and
> see if there are complaints. If they do, I get an error like the
> example at the bottom of this post (in case of an IO standard
> violation), or errors about problems in clock routing. For a few
> years, this has been my method to quickly approve pinouts, until this
> method failed recently.
>
> What I found out, is that the tools agreed to place LVTTL pins and
> LVCMOS25 on the same bank, if they were defined as inouts (that is,
> bidirectional). I verified this by looking at the pad report and with
> FPGA editor. If I made both pins outputs, the tools refused, as they
> should. Other irrelevant tweaks with the code (such as commenting out
> irrelevant parts) also woke up the sleeping guard.
>
> The method I use for checking is instantiating a module like at the
> bottom of this message. The IOSTANDARD parameter is set at
> instantiation to the desired standard. The module generates DDR flip-
> flops for both input and output, so if placement and routing succeeds,
> I know that the certain pin's placement is OK, and that IOB registers
> with the given clock can be packed. Or so I thought.
>
> I have, of course, other modules for input-only, output-only,
> nonclocked IOs, differential IOs and such.
>
> This looks like a bug in the tools. Unfortunately, I failed to make a
> simple example which demonstrates the bug. It looks like the tools are
> OK most of the time, but it's disturbing that they may fail on me even
> once (and make me approve a faulty board design).
>
> So has anyone encountered a similar problem?
>
> Thanks in advance,
> =A0 =A0 Eli
>
> ---------------------------
>
> Example of error from placer.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>
> ERROR:Place:864 - Incompatible IOB's are locked to the same bank 3
> =A0 =A0Conflicting IO Standards are:
> =A0 =A0IO Standard 1: Name =3D LVCMOS25, VREF =3D NR, VCCO =3D 2.50, TERM=
=3D NONE
> =A0 =A0List of locked IOB's:
> =A0 =A0 =A0 =A0 data<0>
> =A0 =A0 =A0 =A0 data<1>
>
> =A0 =A0IO Standard 2: Name =3D LVTTL, VREF =3D NR, VCCO =3D 3.30, TERM =
=3D NONE
> =A0 =A0List of locked IOB's:
> =A0 =A0 =A0 =A0 testpoints<1>
> =A0 =A0 =A0 =A0 testpoints<3>
>
> The test module
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> module testiob #(parameter IOSTANDARD =3D "LVTTL")
> =A0 =A0(inout pin,
> =A0 =A0 input clk);
>
> =A0 =A0wire =A0 in, out, T;
> =A0 =A0wire =A0 in_fall, in_rise;
>
> =A0 =A0reg =A0 =A0in_fall_d, in_rise_d;
>
> =A0 =A0always @(posedge clk)
> =A0 =A0 =A0begin
> =A0 =A0 =A0 =A0 in_fall_d <=3D in_fall;
> =A0 =A0 =A0 =A0 in_rise_d <=3D in_rise;
> =A0 =A0 =A0end
>
> =A0 =A0// This is completely useless setting. It just puts the IOB in
> place.
> =A0 =A0// It may drive the lines crazy if used for real
>
> =A0 =A0IOBUF =A0#(.IOSTANDARD(IOSTANDARD)) iobuf
> =A0 =A0 =A0(.IO(pin), .I(out), .O(in), .T(T));
>
> =A0 =A0ODDR2 #(.SRTYPE("ASYNC")) out_ddr
> =A0 =A0 =A0(.Q (out),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE (1'b1),
> =A0 =A0 =A0 .R (1'b0),
> =A0 =A0 =A0 .D0 (in_rise_d),
> =A0 =A0 =A0 .D1 (in_fall_d),
> =A0 =A0 =A0 .S (1'b0));
>
> =A0 =A0ODDR2 #(.SRTYPE("ASYNC")) T_ddr
> =A0 =A0 =A0(.Q (T),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE (1'b1),
> =A0 =A0 =A0 .R (1'b0),
> =A0 =A0 =A0 .D0 (in_rise_d),
> =A0 =A0 =A0 .D1 (in_fall_d),
> =A0 =A0 =A0 .S (1'b0));
>
> =A0 =A0IDDR2 #(.SRTYPE("ASYNC")) in_ddr
> =A0 =A0 =A0(
> =A0 =A0 =A0 .Q0 =A0 (in_rise),
> =A0 =A0 =A0 .Q1 =A0 (in_fall),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE =A0 (1'b1),
> =A0 =A0 =A0 .D =A0 =A0(in),
> =A0 =A0 =A0 .R =A0 =A0(1'b0),
> =A0 =A0 =A0 .S (1'b0));
>
> endmodule
Similar problem, yes. It is possible to specify an invalid IOTYPE
when instantiating an IOBUF. Not a single step in the chain detects
it - it goes all the way -through- bitgen without a single warning.
"Version 12 will fix it" (And it will pick winning lotto numbers
too!)
RK
Article: 147417On Apr 26, 4:09=A0pm, Wastrel <stephensdigi...@gmail.com> wrote: > On Apr 25, 11:54=A0pm, David Brown <da...@westcontrol.removethisbit.com> > wrote: > > > > > On 23/04/2010 21:39, Rich Webb wrote: > > > > On Fri, 23 Apr 2010 10:19:07 -0700 (PDT), Wastrel > > > <stephensdigi...@gmail.com> =A0wrote: > > > >> On Apr 21, 1:08 pm, Jon Beniston<j...@beniston.com> =A0wrote: > > >>> It's running ok for me on Windows 7 64-bit. > > > >>> What particular part of the software are you having problems with? > > > >>> Jon > > > >> Well it installs alright, but Altium Designer 6 can't find it - > > >> whereas it did on my XP box. One problem is that Windows 7 likes to > > >> put 32 bit legacy programs under Program FIles(x86), but Quartus won= 't > > >> install there because it can't handle spaces or special characters i= n > > >> it's filenames. > > > > Tell it to use the 8.3 name for the directory (one way of seeing this= is > > > to do a "dir /X" from a command prompt). For the directory above, the > > > name would be "c:\progra~2\". > > > Alternatively, avoid "Program Files" or "Program Files (x86)" like the > > plague - these are seriously stupid path names MS has chosen. > > > When installing almost any new software, you have a free choice of the > > installation path - if you think you might ever want to refer to the > > program or its files by path name (such as the command line), use > > something like "c:\Progs\" as the base instead of "c:\Program Files". > > > I have no idea whether this will help you here or not, but it will avoi= d > > the awkward installation path.- Hide quoted text - > > > - Show quoted text - > > Well Altium support got back to me and said basically the same thing > you guys are: "It works OK for me" > > They told me to verify that the system environment variable > "QUARTUS_ROOTDIR" pointed to the right folder - it did. I upgraded the > OS to Windows 7 Professional from "Home Premium" still no joy. When I > run Windows' compatibility troubleshooter it comes back with > "Incompatible Application" so there's something funky going on. I'm > wasting way to much time on this stupid problem, but it's not so easy > finding an XP box anymore so I'm not just sure what my next move is. If you are running Win7 Pro, and your hardware supports virtualization, you might consider installing the XP VM from Microsoft. It's a full-function version of Windows XP SP3, and it runs in a VM environment a bit like Parallels on the Mac. (IOW, applications appear on the desktop like any other, rather than in a separate VM window) Best of all, it's free for Win7 Pro and higher. Of course, you would need to install both Altium and Quartus in the VM, but that should replicate your old environment fairly closely. I believe the VM is 32-bit only. While it will run on a 64-bit OS, you will be limited to less than 4GB of RAM. Note, I haven't tried it - since my only Win7 machine doesn't have the right CPU support - but this is the sort of scenario it was meant for.Article: 147418
Martin Br?ckner <bj2spam@alice-dsl.net> wrote: > I'm writing a boot loader to start Linux on the PowerPC440 (Virtex5FXT). > At first the program copies the kernel into the RAM at address > 0x00400000 and afterwards it boots Linux with the following lines: > #define LINUX_START_ADDRESS 0x004002b4 (snip) > (*linux)(); With the assumption that data pointers can be properly cast to function pointers, that line should jump to location 0x4002b4 and start executing the code there. > With the following steps, booting works fine: > (1). comment out the line (*linux)(); > (2). start the program > (3). start xmd and enter "rst -processor" > (4). set the program counter: "rwr pc 0x004002b4" > (5). enter "con" I presume that mostly starts executing at 0x4002b4? > What does not work: > Starting Linux directly within the program with the last line. > All I can see is the following and thats all. > zImage starting: loaded at 0x00400000 (sp: 0x00569fb0) > Allocating 0x2efa98 bytes for kernel ... > gunzipping (0x00000000 <- 0x0040d000:0x0056837e)...done 0x2d2270 bytes > Linux/PowerPC load: console=ttyUL0 root=/dev/mmcblk0p1 rootdelay=5 > Finalizing device tree... flat tree at 0x576300 So it does start executing, and doing things that it is supposed to do, but doesn't end up working? > So the question is: What do I have to do to boot Linux from within the > program? -- glenArticle: 147419
On Apr 26, 10:23=A0am, Eric <eric.lafor...@gmail.com> wrote: > > Yep, you are right. The number of BlockRAMs required is M*N, plus the > LVT (which uses no Block RAMs). > Thanks for the explanation of the XOR design. You're the first to do > so. It makes a lot of sense, except I don't see why you need the extra > M-1 memories on the read side? Because the write of the new data is the DataIn XORed with the old data at the new WrAddr, each write address needs a read from the other write memory sets. For M write ports, there are M write sets. Each write set has the N read memories for the N-port read and also has M-1 reads from_the_other_write_addresses to complete the XORed data value to store to those write sets.Article: 147420
Wastrel <stephensdigital@gmail.com> wrote: (snip) > Well Altium support got back to me and said basically the same thing > you guys are: "It works OK for me" > They told me to verify that the system environment variable > "QUARTUS_ROOTDIR" pointed to the right folder - it did. I upgraded the > OS to Windows 7 Professional from "Home Premium" still no joy. When I > run Windows' compatibility troubleshooter it comes back with > "Incompatible Application" so there's something funky going on. I'm > wasting way to much time on this stupid problem, but it's not so easy > finding an XP box anymore so I'm not just sure what my next move is. As I understand it, starting with Vista Windows won't run 16 bit code anymore. It seems that a surprising amount of such code still exists and causes problems, though I am a little surprised it would happen in this case. -- glenArticle: 147421
Cliff's paper is about avoiding race conditions. However, in vhdl "blocking assignements" (to unshared variables) are limited to local process/subprogram scope anyway, so you never have problems with race conditions with them. That is why it is safe and even beneficial to use blocking assignments (to unshared variables) in VHDL clocked processes. Combine that with the flexibility afforded in describing both combinatorial and sequential logic in the same process, and it makes for an extremely powerful, yet safe concept. While some may struggle with identifying where the registers are located in relation to the combinatorial logic, understanding the cycle-based behavior is more intuitive, since the code "reads and executes like SW". Given the increasing use of retiming optimizations, knowing where registers are located in your RTL is rapidly becoming useless anyway. For the remaining < 1% of the time when I need an in-to-out combinatorial logic path through a module/entity, I'll go ahead and use a combinatorial process (implied by a concurrent assignment or otherwise). That doesn't mean I'm going to throw away the benefits of using only clocked processes for the other > 99%, just for purity's sake. AndyArticle: 147422
On Apr 26, 7:15=A0pm, Andy <jonesa...@comcast.net> wrote: > Cliff's paper is about avoiding race conditions. However, in vhdl > "blocking assignements" (to unshared variables) are limited to local > process/subprogram scope anyway, so you never have problems with race > conditions with them. That is why it is safe and even beneficial to > use blocking assignments (to unshared variables) in VHDL clocked > processes. Combine that with the flexibility afforded in describing > both combinatorial and sequential logic in the same process, and it > makes for an extremely powerful, yet safe concept. While some may > struggle with identifying where the registers are located in relation > to the combinatorial logic, understanding the cycle-based behavior is > more intuitive, since the code "reads and executes like SW". Given the > increasing use of retiming optimizations, knowing where registers are > located in your RTL is rapidly becoming useless anyway. > > For the remaining < 1% of the time when I need an in-to-out > combinatorial logic path through a module/entity, I'll go ahead and > use a combinatorial process (implied by a concurrent assignment or > otherwise). That doesn't mean I'm going to throw away the benefits of > using only clocked processes for the other > 99%, just for purity's > sake. Yes, the two process model probably isn't nearly as useful in VHDL. As others have been quick to point out, you don't need a combinatorial process in verilog either, but then you have to be careful about blocking vs. non-blocking, not using variables which have blocking assignments to them from other processes, etc. The two process model is simply an organizing principle that provides a separation of concerns and simplifies the rules a bit, making it easier to reason about the code. Extremely simple code doesn't gain anything from using this model, but a lot of real-world code does. Regards, PatArticle: 147423
On Apr 22, 5:41=A0pm, alk...@yahoo.co.uk wrote: > Hi, > i am confused regarding the ADC/DAC interface implementation on FPGA. > I have read a code where after serialising the input data of 16 bits > in 16 clock cycles, the interface logic loops (in vain?) for another > 16 cyles =A0before serialising the next data. can#t understand why? why > the serialisation of the next data is not done immediately. moreover, > should the serialisation clock rate be 16 higher than the data stream > clock rate? Sorry but i could not find a documentation detailing all > the synchronization mechanism. > > cheers :) For details of this, look up a UART in a text book. Here is a hint in the right direction. Assume that data (digital or analog) is transmitted between two devices at a certain rate, but asynchronously ie: no clock in the interface. Can the receive clock be the same frequency of the transmit clock? Assume there is no way to guarantee any relationship between the two clocks. In fact, it is common for them to be slightly different in frequency. If the sample clock is 16X faster than the transmit, the middle of a cycle is found when a start indication is found 8 times. Then capturethe data values once every 16 times (because the receive clockis 16X faster). With this slight differences in frequency can be tolerated - depending how many samples are taken between realigning with a start bit. Good Luck, Jim SynthWorks VHDLArticle: 147424
Am Mon, 26 Apr 2010 22:08:02 +0000 (UTC) schrieb glen herrmannsfeldt <gah@ugcs.caltech.edu>: > Martin Br?ckner <bj2spam@alice-dsl.net> wrote: > > > I'm writing a boot loader to start Linux on the PowerPC440 > > (Virtex5FXT). At first the program copies the kernel into the RAM > > at address 0x00400000 and afterwards it boots Linux with the > > following lines: > > > #define LINUX_START_ADDRESS 0x004002b4 > > (snip) > > > (*linux)(); > > With the assumption that data pointers can be properly > cast to function pointers, that line should jump to > location 0x4002b4 and start executing the code there. > > > With the following steps, booting works fine: > > (1). comment out the line (*linux)(); > > (2). start the program > > (3). start xmd and enter "rst -processor" > > (4). set the program counter: "rwr pc 0x004002b4" > > (5). enter "con" > > I presume that mostly starts executing at 0x4002b4? Yes. > > > What does not work: > > Starting Linux directly within the program with the last line. > > All I can see is the following and thats all. > > > zImage starting: loaded at 0x00400000 (sp: 0x00569fb0) > > Allocating 0x2efa98 bytes for kernel ... > > gunzipping (0x00000000 <- 0x0040d000:0x0056837e)...done 0x2d2270 > > bytes > > > Linux/PowerPC load: console=ttyUL0 root=/dev/mmcblk0p1 rootdelay=5 > > Finalizing device tree... flat tree at 0x576300 > > So it does start executing, and doing things that it is > supposed to do, but doesn't end up working? Yes, exactly. When resetting the CPU before booting, everything is fine. But in this case it ends up here. At the moment I'm learning how to extract the syslog out of Linux to get messages before the console is initialized. I'll post the result here, soon. > > > So the question is: What do I have to do to boot Linux from within > > the program? > > -- glen -- Martin Brückner
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