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 Aug 17, 8:17=A0pm, rickman <gnu...@gmail.com> wrote: > On Aug 17, 9:17 am, aleksa <aleks...@gmail.com> wrote: > > > When I was inferring dual port BRAM with same data bus sizes, > > I was able to see the contents of BRAM memory locations in ISE > > simulator. > > > Now I'm instatieting (is this word correctly written?) > > dual port BRAM with port A 8bits and port B 1bit wide data bus, > > and I cant get ISE sim to show the memory contents. > > > Is it not possible or am I doing something wrong? > > When you instantiate a vendor supplied component, you are using their > library element. =A0Often this is just a black box that you can't see > into. =A0If you want to be able to view the contents of the BRAM, you > need to infer it instead of instantiating it. =A0Then the HDL code will > be fully visible. =A0BTW, the most efficient simulation uses integers > for the actual memory block rather than std_logic_vector. > > Rick thanksArticle: 134551
"andersod2" <thechrisanderson@gmail.com> wrote in message
news:99b1281a-a30f-4949-b6aa-bbf42c3824dc@y38g2000hsy.googlegroups.com...
>
>
>
> KJ,
> Thanks a lot...I think you may be right because I'm getting a lot of
> latch warnings, but didn't understand why. I am using inferred ram,
> which the docs say will work the same as an explicit template
> instantiation if I just use the typical "reg [w:x] mem[y:z];"
> notation...do you think using a template is always the better way to
> go?
To infer memory in any device you need to follow the template for that
device. For FPGAs, you typically have only synchronous memory (as rickman
and Peter have pointed out), the basic template for this type of memory, in
VHDL is...
process(clk)
begin
if rising_edge(clk) then
if (write_enable = '1') then
ram(write_address) <= write_data;
end if;
read_data <= ram(read_address);
end if;
end process;
> In fact I lifted the code for
> my mem module from a verilog site...
Hopefully one that produces synthesizable Verilog code.
> if there's a a way I can guarantee
> that the inferred ram will be put in a block I would very much like to
> know as I find it much easier to work with than the template. Is that
> a constraints thing?
As I mentioned in the first post, I've found occasion where I had to add an
attribute to the 'read_address' signal in order to get the tool to use the
internal memory. I would suggest:
- Take the above snippet of code (or peruse Xilinx's website for their
template) and get that working in Verilog.
- Build just that module and see if it does indeed get built correctly using
the internal memory.
- Integrate that into your real design and rebuild and check that it also
gets built correctly (this is the point where I found that it wasn't and
needed the extra attribute attached to 'read_address).
- If all else fails, open a case with Xilinx.
KJ
Article: 134552On Aug 15, 3:13=A0pm, stewa...@gmail.com wrote: > I want to implement 1280x1024but cannot synthesize an 108MHz pixel > block for the timing. =A0I would prefer to use a 100 MHz (generated from > 200) but can also make a 104 or 112 Mhz. > > Normal 1280x1024 timing: > Horizontal > Resolution pixels: 1280 > Front porch pixels: 48 > Sync pulse pixels: 112 > Back porch pixel: 248 > Veritcle > Resolution lines: 1024 > Front porch lines: 1 > Sync pulse lines: 3 > Back porch lines: 38 > > Has anyone had any experience altering the porch/sync lengths and > pixel clock to keep 60Hz that will sync to an LCD monitor? > > Thanks! Here is a Cyclone III design that takes 4 SD and blends them on top of 1 HD signal and sends it out on DVI with the resolution you require, and it uses the TVP410 which is available for Altera boards from Bitec. It requires a few things to be set it up, so if you want to see it run or recompile you'll need instructions. Otherwise can see all the video timing in the project. Its done in Quartus 8.0 and uses all Altera IP without any HDL (no kidding), so it should be easy to follow dataflow wise. There's a good amount of run-time control, so you can move the PIPs around, resize them using Nios as the controller. The demo: http://www.alteraforum.com/outgoing/VIP_3c120_80.zip instructions (if you want to run it or recompile) http://www.alteraforum.com/outgoing/demo_instructions.doc blkArticle: 134553
Hi All, I have a second hand MJL Cyclone Development kit with Altera EP1C20F400C7 FPGA and EPM3064ATC configuration controller. The factory supplied FLASH code is GERMS built using NIOS I. I have successfully compiled a test file using Quartus II, V7.2. I have also loaded and run the SRAM Object File (.SOF) file using a USB Byte Blaster using the JTAG interface. I am now trying to convert the .SOF into a .FLASH format for loading into the FLASH on the development board using the GERMS debugger. The conversion process I have used so far is sof2flash --input=LED.sof --output=LED.flash --offset=0x01300000 The loading process I have used is ./Nios-run p com2 led.flash Using GERMS (m01300000) I can confirm that the code has been programmed into FLASH but the test code does not run. I have been around the houses for several hours and am running out of ideas. Any thoughts ? Many thanks, MarkArticle: 134554
On Aug 17, 8:21 pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "andersod2" <thechrisander...@gmail.com> wrote in message > > news:99b1281a-a30f-4949-b6aa-bbf42c3824dc@y38g2000hsy.googlegroups.com... > > > > > KJ, > > Thanks a lot...I think you may be right because I'm getting a lot of > > latch warnings, but didn't understand why. I am using inferred ram, > > which the docs say will work the same as an explicit template > > instantiation if I just use the typical "reg [w:x] mem[y:z];" > > notation...do you think using a template is always the better way to > > go? > > To infer memory in any device you need to follow the template for that > device. For FPGAs, you typically have only synchronous memory (as rickman > and Peter have pointed out), the basic template for this type of memory, in > VHDL is... > > process(clk) > begin > if rising_edge(clk) then > if (write_enable = '1') then > ram(write_address) <= write_data; > end if; > read_data <= ram(read_address); > end if; > end process; > > > In fact I lifted the code for > > my mem module from a verilog site... > > Hopefully one that produces synthesizable Verilog code. > > > if there's a a way I can guarantee > > that the inferred ram will be put in a block I would very much like to > > know as I find it much easier to work with than the template. Is that > > a constraints thing? > > As I mentioned in the first post, I've found occasion where I had to add an > attribute to the 'read_address' signal in order to get the tool to use the > internal memory. I would suggest: > - Take the above snippet of code (or peruse Xilinx's website for their > template) and get that working in Verilog. > - Build just that module and see if it does indeed get built correctly using > the internal memory. > - Integrate that into your real design and rebuild and check that it also > gets built correctly (this is the point where I found that it wasn't and > needed the extra attribute attached to 'read_address). > - If all else fails, open a case with Xilinx. Please keep in mind that when looking for templates, it is not the logic vendor who sets the standard, it is the synthesis tool vendor. So rather than looking at the Xilinx/Altera/Lattice site, I suggest that you look at Synplicity/Mentor... depending on your tool. RickArticle: 134555
On 13 ao=FBt, 23:56, Manny <mlou...@hotmail.com> wrote: > Hi, > > I don't know why whenever I try to connect via XMD to a preloaded > Ultracontroller-II design, I get the following error: > ERROR: PowerPC405 Version UNKNOWN. The PowerPC405 Config String is Not > Valid : 0xffffffff. > > I'm working with an ml403 v4fx board. I then switch back to SYS ACE > and XMD works again, i.e. overwrite my FPGA. > > Another issue that I'm not sure about is the following: I'm trying to > route a clock through one of the gpio's but can't scope anything. Is > it to do with the DEBUGHALT method used by UC? > > This Ultracontroller thing has given me some fair grief already. Would > be grateful for any insight/tip. > > Cheers, > -Manny My advice would be to avoid the Ultracontroller completely. I used the UC-II in my master's project and would probably not use it again. The workflow is quite different than the normal EDK flow and as a result, you run into all kinds of problems. The UC advantages are not worth the problems in my opinion. Xilinx seem to agree, the UC-II ref designs have not been updated since 2005 as far as I can tell... PatrickArticle: 134556
On Sun, 17 Aug 2008 09:49:30 +0100, "Symon" <symon_brewer@hotmail.com> wrote: <snip> Thanks to one and all. The DCM approach had occured to me. The DDR approach I'll look into. The comment that program is designed to calculate delays from input A to output B, rather than between output B and output C, confirms a vague suspicion I'd already formed. Thanks again!Article: 134557
On Aug 18, 10:06=A0am, rickman <gnu...@gmail.com> wrote: > On Aug 17, 8:21 pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > > Please keep in mind that when looking for templates, it is not the > logic vendor who sets the standard, it is the synthesis tool vendor. > So rather than looking at the Xilinx/Altera/Lattice site, I suggest > that you look at Synplicity/Mentor... depending on your tool. > > Rick Good point, but in this particular instance the synthesis tool that is being used is 'Webpack ISE' from Xilinx. KJArticle: 134558
As many of you are aware, Xilinx has had a re-organization to provide focus, and better serve our customers. My role has changed, and as part of that change, I no longer will be posting here on c.a.f. I strongly recommend that folks try our forums at: http://forums.xilinx.com/xlnx/ where there is a healthy activity. If you have a problem, webcase is also the best and fastest way to get an answer (as a Xilinx customer). If you are a student, you need to ask your professor, who then has access to our support. I am always available at my xilinx.com email address, and I will reply as I am able, to help resolve any technical issues not resolved by the above methods. Austin LeseaArticle: 134559
Un bel giorno austin digiṭ: > I strongly recommend that folks try our forums at: You should give the possibility to access the forums also with NNTP and a news client. Web forums are disappointing. -- emboliaschizoide.splinder.comArticle: 134560
On Aug 18, 10:04=A0am, austin <aus...@xilinx.com> wrote: > As many of you are aware, > > Xilinx has had a re-organization to provide focus, and better serve > our customers. =A0My role has changed, and as part of that change, I no > longer will be posting here on c.a.f. > <snip> > > Austin Lesea I'll be in the group that misses your regular involvement here. I hope your new challenges give you great satisfaction and brings us - the customers - better products. Thanks, - John HandworkArticle: 134561
Hi! I am trying out my first S-3AN design and immediatley stumbled on a problem when connecting the Platform Cable USB II to the JTAG port. I had expected to find a chain of 2 devices, the FPGA and the SPI Flash, but that was not the case. Only one device found and Impact didn't even recognize that as a Xilinx device. Oddly enough, it did seem report deduced values om M[2:0] and VS[2:0] that matched the setting on the board, but I could not assign the bitfile to the device. Most likley this is caused by some dumb error of mine, possibly even a faulty board (an original design that is currently only in one sample), so I do not expect to get any immediate help here, but if by chance anyone has had a similar experiance, I might benifit from that. Also if someone who has worked more with S-3AN can tell me what to expect in terms of JTAG topology, that would be much appreciated. I will do some more debugging tomorrow night and will add any findings to this (rather meagre) post after that. Thanks! /Lars P.S. Remove the obvious from my email address if you want to answer directly. D.S.Article: 134562
Ok, thanks much guys. Haven't had time to work on this the last couple of days, so will get back to it soon. I was indeed using async ram and had no idea that synchronous was required. I read in one of the xilinx docs (can't remember which) that the above declaration I posted was all I needed for inference. I think I will go the instantiation route, though as that seems a bit more sure-fire. Will post if I have more problems with that route.Article: 134563
On Aug 18, 5:10 pm, andersod2 <thechrisander...@gmail.com> wrote: > Ok, thanks much guys. Haven't had time to work on this the last > couple of days, so will get back to it soon. I was indeed using async > ram and had no idea that synchronous was required. I read in one of > the xilinx docs (can't remember which) that the above declaration I > posted was all I needed for inference. I think I will go the > instantiation route, though as that seems a bit more sure-fire. Will > post if I have more problems with that route. Keep in mind that when using instantiation it can be hard, if not impossible to view the contents of RAM since this is a black box to the simulator. You will only be able to see the inputs and outputs. If you infer the RAM, you can directly view it to see what was written at any given time. I expect that inferred RAM will model correctly when performing a post-route timing simulation. RickArticle: 134564
I want to run some simulations where I change one controlling parameter that selects the specifics of the test bench. Is there a way to do that without recompiling the source code? It seems like there should be an input to the simulation other than the source code files. I know this is available in C compiles. A define value can be set from the command line. I looked in the Active HDL help file, but unless you know what you are looking for and what it is called, their search is hard to use. RickArticle: 134565
austin wrote: > As many of you are aware, > > Xilinx has had a re-organization to provide focus, and better serve > our customers. My role has changed, and as part of that change, I no > longer will be posting here on c.a.f. > > I strongly recommend that folks try our forums at: > > http://forums.xilinx.com/xlnx/ > > where there is a healthy activity. > > If you have a problem, webcase is also the best and fastest way to get > an answer (as a Xilinx customer). > > If you are a student, you need to ask your professor, who then has > access to our support. > > I am always available at my xilinx.com email address, and I will reply > as I am able, to help resolve any technical issues not resolved by the > above methods. > > Austin Lesea I do very little work with FPGAs, and none at all with Xilinx (I work mostly with microcontrollers), and seldom post here. But I will miss your input in this group - it is often precisely because I *don't* work with you parts that it is useful other ideas and opinions. Altera are sadly underrepresented in this group because they aim more for web forums - I would prefer a greater mix (even if it means more "my FPGA is bigger than your FPGA" threads - they can be informative and entertaining if they can keep a polite tone), not more specialisation. mvh., DavidArticle: 134566
rickman <gnuarm@gmail.com> writes: > On Aug 18, 5:10 pm, andersod2 <thechrisander...@gmail.com> wrote: >> Ok, thanks much guys. Haven't had time to work on this the last >> couple of days, so will get back to it soon. I was indeed using async >> ram and had no idea that synchronous was required. I read in one of >> the xilinx docs (can't remember which) that the above declaration I >> posted was all I needed for inference. I think I will go the >> instantiation route, though as that seems a bit more sure-fire. Will >> post if I have more problems with that route. > > Keep in mind that when using instantiation it can be hard, if not > impossible to view the contents of RAM since this is a black box to > the simulator. Certainly the Xilinx models are not black-box to the simulaator - they are still written in VHDL. They can be a bit cryptic for the user, especially if you've instantiated (or coregen'ed) a set of RAMs, one for each data bit, but the info is all there. Having said that, I haven't had the need to instantiate a RAM, except in the case of a dual-port RAM with two different clocks, which my current synth tools can't infer. <snip> Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 134567
On Tue, 19 Aug 2008 09:31:57 +0100, Martin Thompson wrote: >Having said that, I haven't had the need to instantiate a RAM, except >in the case of a dual-port RAM with two different clocks, which my >current synth tools can't infer. Hmmmm.... I've been playing with a cache design that needs rather wide data words. I decided I could get 72-bit wide single-port memory out of just one BlockRAM by using both ports simultaneously, with addresses that were identical save for just one bit that was tied to 0 on one port and tied to 1 on the other. I wrote a nice inference model... Two major synth tools correctly inferred the memory as a write-first BlockRAM, but inferred two distinct RAM blocks instead of using both ports, thereby wasting half of each block. ISE 8.2 (yeah, I know it's ancient, but I haven't got around to installing anything newer yet) just locked-up with 100% CPU usage, presumably because it failed to infer the RAM from my description and was trying to build a gazillion registers instead. Must go look up the correct inference templates for XST :-) Does anyone know how to pull this double-width/single-port trick without using instantiation? -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 134568
was actually trying something very similar myself...perhaps same problem...that's why I'm going for instantiation for now...tell me if you find a good inference model...Article: 134569
On Tue, 19 Aug 2008 10:15:50 +0100, Jonathan Bromley wrote:
>ISE 8.2 (yeah, I know it's ancient, but I haven't got
>around to installing anything newer yet) just locked-up
>with 100% CPU usage, presumably because it failed to
>infer the RAM from my description and was trying to
>build a gazillion registers instead. Must go look up
>the correct inference templates for XST :-)
Ahah! Got it...
XST User Guide is a bit woolly about Verilog
RAM inference. It turns out that this form is OK:
always @(posedge clock)
if (enable) begin
if (write) begin
mem[address] <= write_data;
read_data <= write_data ;
end else begin
read_data <= mem[address];
end
end
but this form is not - it hangs XST:
always @(posedge clock)
if (enable) begin
if (write) begin
mem[address] = write_data;
end
read_data <= mem[address];
end
Despite what it says in the XST user guide, it seems
that the same story applies in VHDL: the memory store
must be a signal.
Have I missed something?
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 134570On Aug 18, 1:04=A0pm, austin <aus...@xilinx.com> wrote: > I strongly recommend that folks try our forums at: > > http://forums.xilinx.com/xlnx/ > > where there is a healthy activity. By many people just looking for someone to do their work. At its re- birth, it was filled with a decent amount of people honestly posting about questions and problems. Now it has turned into a haven for those who don't even take the time to read the names of the buttons on the GUIs. They just so happened to get something from somewhere and then they wonder why it doesn't work. </rant> I actually stopped browsing through it a few months back because of the deluge of questions that either were barely comprehensible or just down right looking for someone to fix their stuff. I have since started reading it again, but am still a little underwhelmed. I will definitely miss you here on caf. I still look forward to reading your "blog" posts on the forums. -- MikeArticle: 134571
On Aug 19, 5:15 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Tue, 19 Aug 2008 09:31:57 +0100, Martin Thompson wrote: > >Having said that, I haven't had the need to instantiate a RAM, except > >in the case of a dual-port RAM with two different clocks, which my > >current synth tools can't infer. > > Hmmmm.... I've been playing with a cache design that needs > rather wide data words. I decided I could get 72-bit wide > single-port memory out of just one BlockRAM by using both > ports simultaneously, with addresses that were identical > save for just one bit that was tied to 0 on one port and > tied to 1 on the other. > > I wrote a nice inference model... > > Two major synth tools correctly inferred the memory as > a write-first BlockRAM, but inferred two distinct RAM > blocks instead of using both ports, thereby wasting > half of each block. > > ISE 8.2 (yeah, I know it's ancient, but I haven't got > around to installing anything newer yet) just locked-up > with 100% CPU usage, presumably because it failed to > infer the RAM from my description and was trying to > build a gazillion registers instead. Must go look up > the correct inference templates for XST :-) > > Does anyone know how to pull this double-width/single-port > trick without using instantiation? I don't know for sure, but I expect you can make it work by inferring a standard dual port memory where both ports access the same address space. I expect the vendors have a template for that. Then just feed the two addresses with the high bit set or clear depending on the port. The source you show below may infer memory, but it is single port. I don't see any reason to expect the tools to be able to recognize that you are using half of two memories and they can combine them into one dual port memory. RickArticle: 134572
always @(posedge clock)
if (enable1) begin
if (write1) begin
mem[address1] <= write_data1;
read_data1 <= write_data1 ;
end else begin
read_data1 <= mem[address1];
end
end
if (enable2) begin
if (write2) begin
mem[address2] <= write_data2;
read_data2 <= write_data2 ;
end else begin
read_data2 <= mem[address2];
end
end
How about this as a dual port memory?
Rick
Article: 134573On Tue, 19 Aug 2008 06:20:51 -0700 (PDT), rickman wrote: > > always @(posedge clock) > if (enable1) begin > if (write1) begin > mem[address1] <= write_data1; > read_data1 <= write_data1 ; > end else begin > read_data1 <= mem[address1]; > end > end > if (enable2) begin > if (write2) begin > mem[address2] <= write_data2; > read_data2 <= write_data2 ; > end else begin > read_data2 <= mem[address2]; > end > end > > >How about this as a dual port memory? It's a fine model, but I can't find a synth tool that will infer DP memory when both ports can write. If only one of the two ports has write, it's OK. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 134574
> Hi, > How does the vertical migration, using different parts with the same package work with the altera > cyclone 3 devices? For the EP3C40 and > EP3C16 parts in the FBGA464 packages, pin D7 is gnd on the 16K part, > and D7 is diffio on the 40K part. Also some gnd pins on the 40K part > are I/O on the 16K part. So to design a PCB that can work with both of > these parts alot of extra I/O will have to be grounded I guess? > cheers, > Jamie Jamie, Be careful here the documentation's not that clear, you could easily get your fingers burnt with this migration. We discovered that the vref's change position between the different devices that are supposed to be 'easily' migrate-able. It took a big spreadsheet cross-referencing the three parts (we wanted to be able to use the '55 too) to get a pinout that was compatable. Nial.
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