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 Nov 11, 1:16=A0am, sundar <sundar....@gmail.com> wrote: > On Nov 10, 3:45=A0pm, lomtiks...@gmail.com wrote: > > > > > Hi, > > > I am facing an issue of accessing the registers of a peripheral > > sitting on the DCR bus via PLBV46 to DCR Bridge and uBlaze. The uBlaze > > is on the PLB bus. The bridge is a slave on PLB and a master on DCR. > > Please see below for a snippet of the .mhs file. > > > Since my peripheral has the C_DCR_BASEADDR =3D 0b0000000000, I assume i= t > > is register 0 on the PLB2DCR bridge and I can simply access it by > > looking at the base address of the PLB2DCR. For example, > > write_adress (0x87000000, value1) > > write_adress (0x87000004, value2) > > Does it make sense? > > > BEGIN plbv46_dcr_bridge > > =A0PARAMETER INSTANCE =3D plbv46_dcr_bridge_0 > > =A0PARAMETER HW_VER =3D 1.00.a > > =A0PARAMETER C_BASEADDR =3D 0x87000000 > > =A0PARAMETER C_HIGHADDR =3D 0x8700ffff > > =A0BUS_INTERFACE SPLB =3D mb_plb > > =A0BUS_INTERFACE MDCR =3D dcr_v29_0 > > END > > > BEGIN xps_tft > > =A0PARAMETER INSTANCE =3D xps_tft_0 > > =A0PARAMETER HW_VER =3D 1.00.a > > =A0PARAMETER C_DCR_SPLB_SLAVE_IF =3D 0 > > =A0PARAMETER C_TFT_INTERFACE =3D 0 > > =A0PARAMETER C_DEFAULT_TFT_BASE_ADDR =3D 0x10800000 > > =A0PARAMETER C_DCR_BASEADDR =3D 0b0000000000 > > =A0PARAMETER C_DCR_HIGHADDR =3D 0b0000000011 > > =A0BUS_INTERFACE MPLB =3D mb_plb > > =A0BUS_INTERFACE SDCR =3D dcr_v29_0 > > =A0PORT TFT_VSYNC =3D VGA_VSYNCH > > =A0PORT TFT_HSYNC =3D VGA_HSYNCH > > =A0PORT TFT_VGA_CLK =3D VGA_OUT_PIXEL_CLOCK > > =A0PORT SYS_TFT_Clk =3D tft_clk > > =A0PORT TFT_DE =3D VGA_OUT_BLANK_Z > > =A0PORT DCR_Rst =3D sys_bus_reset > > =A0PORT DCR_Clk =3D sys_clk_s > > =A0PORT TFT_VGA_R =3D VGA_OUT_RED > > =A0PORT TFT_VGA_G =3D VGA_OUT_GREEN > > =A0PORT TFT_VGA_B =3D VGA_OUT_BLUE > > END > > > Thank you in advance > > Hi, > > I am not sure how your other EDK setup files looks like but still thot > of sharing some info. > Note: PLB can be configured as 32,63 or 128 dwidth and address access > is by default 32. > DCR address access is 10 width so please study address translation > section of the Product spec. > Now coming to direct query ....the bridge core has registers > classified as slave access registers,interrupt registers. > I think slave access register may not start from 0. In this case DCR > is slave so make sure you are setting proper reg address space. > > Hope this helps. > > Sundar Thanks for your comments, Sundar. Following your advice, I've searched for slave access registers in plb2dcr bridge and tft controller and have not found the restrictions. There is a restriction for tft connected as slave on the plb bus, but from the eng doc it looks like it is an option for PPC only. I am using microblaze. In any case, I changed C_DCR_BASEADDR of tft controller peripheral to from 0b0010000000 to 0b0010000011 as one of the "ml401_emb_ref_71\projects\ml401_emb_ref" examples I found for ml401 board (it also uses microblaze, but opb2dcr bridge and tft on the dcr as a slave). Still I cannot change the register setting which is supposed to change the frame buffer pointer of the tft. Note that TFT is working fine for the default address that gets programmed with the bitstream (I can see the picture, but I cannot change to another memory location). 2. So, to debug it further, I realized that I might have misconnected the ports on my peripheral. Previously, the xps_tft's DCR_Rst and DCR_Clk were connected to my 100MHz sys_bus_reset and sys_clk_s respectively and plb2dcr_bridge's PLB_dcrRst and PLB_dcrClk-- unconnected. So now, I connected these together because from the eng doc it looks like the PLB's clock has to clock the DCR via BUS2IP_Clk of the bridge. So my mhs file is as below now, but still I cannot access the registers. BEGIN xps_tft PARAMETER INSTANCE =3D xps_tft_0 PARAMETER HW_VER =3D 1.00.a PARAMETER C_DCR_SPLB_SLAVE_IF =3D 0 PARAMETER C_TFT_INTERFACE =3D 0 PARAMETER C_DEFAULT_TFT_BASE_ADDR =3D 0x10800000 PARAMETER C_DCR_BASEADDR =3D 0b0010000000 <----------changed from 0b0000000000 PARAMETER C_DCR_HIGHADDR =3D 0b0010000011 <----------changed from 0b0000000011 BUS_INTERFACE MPLB =3D mb_plb BUS_INTERFACE SDCR =3D dcr_v29_0 PORT TFT_VSYNC =3D VGA_VSYNCH PORT TFT_HSYNC =3D VGA_HSYNCH PORT TFT_VGA_CLK =3D VGA_OUT_PIXEL_CLOCK PORT SYS_TFT_Clk =3D tft_clk PORT TFT_DE =3D VGA_OUT_BLANK_Z PORT DCR_Rst =3D PLB_TO_DCR_RST PORT DCR_Clk =3D PLB_TO_DCR_CLK PORT TFT_VGA_R =3D VGA_OUT_RED PORT TFT_VGA_G =3D VGA_OUT_GREEN PORT TFT_VGA_B =3D VGA_OUT_BLUE END BEGIN plbv46_dcr_bridge PARAMETER INSTANCE =3D plbv46_dcr_bridge_0 PARAMETER HW_VER =3D 1.00.a PARAMETER C_BASEADDR =3D 0x87000000 PARAMETER C_HIGHADDR =3D 0x8700ffff BUS_INTERFACE SPLB =3D mb_plb BUS_INTERFACE MDCR =3D dcr_v29_0 PORT PLB_dcrClk =3D PLB_TO_DCR_CLK <------------- new connection PORT PLB_dcrRst =3D PLB_TO_DCR_RST <------------- new connection END 3. I tried reading the memory directly from XMD and got "Debug memory access check failed. Section, 0x87000200-0x8700203 not accessible from processor debug interface. I used 0x87000200 because DCR's offset is 128 (C_DCR_BASEADDR =3D 0b0010000000) and to translate to PLB format, I multiplied by 4 as suggested. However, I also tried other values including 0x87000080, 0x87000100, 0x87000400, 0x87000800, 0x87001000, etc). Same result. It looks like the address is either not decodable or not accessible due to misconnected ports. What do you think?Article: 136326
Schematics and pin constraints files are now available from Polmaddie1 product page http://www.enterpoint.co.uk/cpld_boards/polmaddie1.html. Pricing information has also been added to the engineering webpage and these boards are now fully available. The product is also now in our shop but currently miss-spelled and miss-sectioned but is on discount for anyone that can find it there. Stock indication is also wrong on the shop currently but that should be sorted out within the next few hours. John Adair EnterpointArticle: 136327
On Nov 11, 3:22=A0am, "HT-Lab" <han...@ht-lab.com> wrote: > "timinganalyzer" <timinganaly...@gmail.com> wrote in message > > news:bf961753-a564-4045-b12b-31d524986f31@a17g2000prm.googlegroups.com... > On Nov 10, 5:24 pm, Amal <akhailt...@gmail.com> wrote: > > > > > Does it support verilog1995 VCD? Or Extended VCD format? > > > -- Amal > > > On Nov 7, 10:50 am, timinganalyzer <timinganaly...@gmail.com> wrote: > > > > Hi All, > > > > A newly added feature of the TimingAnalyzer is the ability to > > > read .vcd files. These files can be generated by logic simulators or > > > tools like Xilinx chipscope, or test equipment like logic analyzers. > > > So, you can easily make annotated timing diagrams from simulation or > > > test equipment outputs. > > > > Would it be possible to email any .vcd files samples that you might > > > have, that are not proprietary, so I can test this feature with .vcd > > > files from as many sources as possible? > > > > tiiminganaly...@gmail.com > > > supp...@timing-diagrams.com > > > > Thank you in advance, > > > Dan > > > >www.timing-diagrams.com > > >Currently, =A0just the vcd format, =A0but I could add the extended vcd > >format if requested. > > >Do you know what tools work with the extended format? > > Modelsim is one of them. > > Hanswww.ht-lab.com > > > I have also > >worked with a compressed file format which might of interest to some > >users working with large simulations. > > >Thanks, =A0Dan > > Hi Hans, Could you send me examples of vcd and evcd files generated by Modelsim? Thanks, DanArticle: 136328
To create a four-port (FP)memory, I use a dual-port (DP) blockram (BRAM) similar to Xilinx xapp228. Data and control signals signals to the FP memory are multiplexed by CLK, while the FP memory runs on CLK*2. CLK2*2 is generated by a digital clock manager (DCM) and feedback ensures that edges are aligned. There are other entities running on CLK and their output is used to generate data and control for the FP memory. For long pathes, the multiplexer input active on CLK==0 is used. That way, a delay of 1/CLK (minus the multiplexer delay) is allowed. However in my implementation Xilinx ISE sees a signal starting at a posedge of CLK and ending in a Flipflop clocked with CLK*2. Now only 1/(CLK*2) delay is allowed and the timing constraints are not met. What kind of constraints should be applied? This neither crosses uncorrelated time domains nor is a clear multi-cycle path. Pseudocode would look like: always @ (posedge clk) x_clk <= x; assign y = func(x_clk); assign we = (clk)? z:y; always @(posedge clk*2) if (we) out <= din; and the failing path is posedge clk -> x_clk -> y -> we @(posedge clk*2) Any help/examples welcome! Thanks -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 136329
>Shouldn't make using GSR and the STARTUP primitive make life easier? That's the case that started a long discussion several years ago. [Also, I let it bite me. Once is enough.] Look at the timing. GSR is very slow. On top of that, the timing analyzer doesn't remind you about it and it doesn't work if you have several clocks. The case that bit me was a simple state machine that jumped to a new state as soon as it came out of reset. Different FFs came out of reset at different times simply due to prop times on GSR. So occasionally, my logic powered up in an illegal state. Somebody should write a paper: GSR Considered Harmful, or something like that. (Somebody probably has.) -- These are my opinions, not necessarily my employer's. I hate spam.Article: 136330
> What kind of constraints should be applied? This neither crosses > uncorrelated time domains nor is a clear multi-cycle path. Can you apply a from-to constraint from clk flops to clk2 flops? From- to constraint has higher priority than the clk and clk2 period constraints so it will override those. e.g. TIMESPEC TS_blah_blah = FROM FFS(source_flops_names) to FFS(dest_flop_names) 10ns; Is this virtex or spartan? and what frequency is clk?Article: 136331
Andrew FPGA <andrew.newsgroup@gmail.com> wrote: > > What kind of constraints should be applied? This neither crosses > > uncorrelated time domains nor is a clear multi-cycle path. > Can you apply a from-to constraint from clk flops to clk2 flops? From- > to constraint has higher priority than the clk and clk2 period > constraints so it will override those. > e.g. > TIMESPEC TS_blah_blah = FROM FFS(source_flops_names) to > FFS(dest_flop_names) 10ns; > Is this virtex or spartan? and what frequency is clk? It's Spartan(3E), with CLK = 100 MHz. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 136332
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote: ... > Somebody should write a paper: GSR Considered Harmful, or > something like that. (Somebody probably has.) Somehow done already: http://www.xilinx.com/support/documentation/white_papers/wp272.pdf : Get Smart About Reset: : Think Local, Not Global -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 136333
>How complicated is it to do Viterbi, Reed-Solomon on an FPGA for a >Wimax transmitter on say 2.4ghz implementing OFDM? My understanding is >that that Tilera will provide us with a pure C++ environment and speed >up the development cycle which with FPGA could be a few years for a >full fledged base station. In a typical system, you might have an FPGA do the arithmetic core, possibly with an auxiliary DSP, and some small linux microprocessor off the side running control services. The Tilera chip covers all those. -- mac the naïfArticle: 136334
"guestuser1" <guestuser1@nowhere.net> writes: > *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II) is so slow, > why would you even try to run a full Linux (MMU) kernel on it? Sometimes you need the MMU more than you need the performance. Otherwise we'd all be running uCLinux on our x86 boxes. > It may be academically interesting, but a far more practical setup > would use a Virtex4/FX (PowerPC-405) or a > Virtex5/FXT (PowerPC-440) More practical for what? For some applications cost is more of a concern than maximum CPU performance. The Virtex 4 or Virtex 5 are somewhat expensive; for some applications that's OK and for others it isn't.Article: 136335
Hi... Just beginning to work with these devices using VHDL and and Active-HDL as my design tools. One thing (actually, many) that I don't understand: CPLDs contain Global clock pins, sometimes 2 or more. What if I needed several more clocks for various blocks? A SPI bus comes to mind, must I use the GClk for this or can I define another pin to represent the SPI sck? If this is true, what are the advantages of using the Global clks pins? Another question: What rule of thumb tricks does one use to get an initial estimate of the required CPLD part size (macro cells, gates) in order to satisfy one's design? thanks any help you may offer. JimArticle: 136336
cs_posting@hotmail.com wrote: > On Nov 10, 12:55 am, "H. Peter Anvin" <h...@zytor.com> wrote: > >> It would still be nice to have more chips with combination >> microcontroller and small FPGA at the low end, as that is often a useful >> mix as opposed to having to have a much bigger FPGA. Aiming this at the >> high-end CPLD markets (with features such as onboard flash, 5V >> tolerance, etc.) would be especially nice. > > My feeling is that when talking about low cost FPGA's, it's not the > logic fabric required to implement a decent microcontroller-class soft > core that's the problem, it's the ram to store the program that is > mostly missing and thus pushes you either into a larger FPGA than > logic demands require, or into using an external memory. > > And flash cells would be nice too, but if doing that might as well > include storage for the FPGA bit file too. Otherwise you can just > append the program code in a serial config flash and load that into > ram to execute from. Or you could if the ram problem were solved... Of course you want to have storage for the FPGA bit file. Additionally, I think you'd really want single voltage, as is pretty much the norm in flash microcontrollers. That's the problem with going to "full" FPGAs like Spartan or Cyclone: the power supply and storage requires some reasonable degree of technical sophistication in the design, whereas most CPLDs and flash microcontrollers can be wired up by a complete board design newbie like myself and expect it to work. -hpaArticle: 136337
On Nov 11, 4:34=A0am, lomtiks...@gmail.com wrote: > On Nov 11, 1:16=A0am, sundar <sundar....@gmail.com> wrote: > > > > > On Nov 10, 3:45=A0pm, lomtiks...@gmail.com wrote: > > > > Hi, > > > > I am facing an issue of accessing the registers of a peripheral > > > sitting on the DCR bus via PLBV46 to DCR Bridge and uBlaze. The uBlaz= e > > > is on the PLB bus. The bridge is a slave on PLB and a master on DCR. > > > Please see below for a snippet of the .mhs file. > > > > Since my peripheral has the C_DCR_BASEADDR =3D 0b0000000000, I assume= it > > > is register 0 on the PLB2DCR bridge and I can simply access it by > > > looking at the base address of the PLB2DCR. For example, > > > write_adress (0x87000000, value1) > > > write_adress (0x87000004, value2) > > > Does it make sense? > > > > BEGIN plbv46_dcr_bridge > > > =A0PARAMETER INSTANCE =3D plbv46_dcr_bridge_0 > > > =A0PARAMETER HW_VER =3D 1.00.a > > > =A0PARAMETER C_BASEADDR =3D 0x87000000 > > > =A0PARAMETER C_HIGHADDR =3D 0x8700ffff > > > =A0BUS_INTERFACE SPLB =3D mb_plb > > > =A0BUS_INTERFACE MDCR =3D dcr_v29_0 > > > END > > > > BEGIN xps_tft > > > =A0PARAMETER INSTANCE =3D xps_tft_0 > > > =A0PARAMETER HW_VER =3D 1.00.a > > > =A0PARAMETER C_DCR_SPLB_SLAVE_IF =3D 0 > > > =A0PARAMETER C_TFT_INTERFACE =3D 0 > > > =A0PARAMETER C_DEFAULT_TFT_BASE_ADDR =3D 0x10800000 > > > =A0PARAMETER C_DCR_BASEADDR =3D 0b0000000000 > > > =A0PARAMETER C_DCR_HIGHADDR =3D 0b0000000011 > > > =A0BUS_INTERFACE MPLB =3D mb_plb > > > =A0BUS_INTERFACE SDCR =3D dcr_v29_0 > > > =A0PORT TFT_VSYNC =3D VGA_VSYNCH > > > =A0PORT TFT_HSYNC =3D VGA_HSYNCH > > > =A0PORT TFT_VGA_CLK =3D VGA_OUT_PIXEL_CLOCK > > > =A0PORT SYS_TFT_Clk =3D tft_clk > > > =A0PORT TFT_DE =3D VGA_OUT_BLANK_Z > > > =A0PORT DCR_Rst =3D sys_bus_reset > > > =A0PORT DCR_Clk =3D sys_clk_s > > > =A0PORT TFT_VGA_R =3D VGA_OUT_RED > > > =A0PORT TFT_VGA_G =3D VGA_OUT_GREEN > > > =A0PORT TFT_VGA_B =3D VGA_OUT_BLUE > > > END > > > > Thank you in advance > > > Hi, > > > I am not sure how your other EDK setup files looks like but still thot > > of sharing some info. > > Note: PLB can be configured as 32,63 or 128 dwidth and address access > > is by default 32. > > DCR address access is 10 width so please study address translation > > section of the Product spec. > > Now coming to direct query ....the bridge core has registers > > classified as slave access registers,interrupt registers. > > I think slave access register may not start from 0. In this case DCR > > is slave so make sure you are setting proper reg address space. > > > Hope this helps. > > > Sundar > > Thanks for your comments, Sundar. > > Following your advice, I've searched for slave access registers in > plb2dcr bridge and tft controller and have not found the restrictions. > There is a restriction for tft connected as slave on the plb bus, but > from the eng doc it looks like it is an option for PPC only. I am > using microblaze. In any case, I changed C_DCR_BASEADDR of tft > controller peripheral to from 0b0010000000 to 0b0010000011 as one of > the "ml401_emb_ref_71\projects\ml401_emb_ref" examples I found for > ml401 board (it also uses microblaze, but opb2dcr bridge and tft on > the dcr as a slave). Still I cannot change the register setting which > is supposed to change the frame buffer pointer of the tft. Note that > TFT is working fine for the default address that gets programmed with > the bitstream (I can see the picture, but I cannot change to another > memory location). > > 2. So, to debug it further, I realized that I might have misconnected > the ports on my peripheral. Previously, the xps_tft's DCR_Rst and > DCR_Clk were connected to my 100MHz sys_bus_reset and sys_clk_s > respectively and plb2dcr_bridge's PLB_dcrRst and PLB_dcrClk-- > unconnected. So now, I connected these together because from the eng > doc it looks like the PLB's clock has to clock the DCR via BUS2IP_Clk > of the =A0bridge. So my mhs file is as below now, but still I cannot > access the registers. > BEGIN xps_tft > =A0PARAMETER INSTANCE =3D xps_tft_0 > =A0PARAMETER HW_VER =3D 1.00.a > =A0PARAMETER C_DCR_SPLB_SLAVE_IF =3D 0 > =A0PARAMETER C_TFT_INTERFACE =3D 0 > =A0PARAMETER C_DEFAULT_TFT_BASE_ADDR =3D 0x10800000 > =A0PARAMETER C_DCR_BASEADDR =3D 0b0010000000 <----------changed from > 0b0000000000 > =A0PARAMETER C_DCR_HIGHADDR =3D 0b0010000011 <----------changed from > 0b0000000011 > =A0BUS_INTERFACE MPLB =3D mb_plb > =A0BUS_INTERFACE SDCR =3D dcr_v29_0 > =A0PORT TFT_VSYNC =3D VGA_VSYNCH > =A0PORT TFT_HSYNC =3D VGA_HSYNCH > =A0PORT TFT_VGA_CLK =3D VGA_OUT_PIXEL_CLOCK > =A0PORT SYS_TFT_Clk =3D tft_clk > =A0PORT TFT_DE =3D VGA_OUT_BLANK_Z > =A0PORT DCR_Rst =3D PLB_TO_DCR_RST > =A0PORT DCR_Clk =3D PLB_TO_DCR_CLK > =A0PORT TFT_VGA_R =3D VGA_OUT_RED > =A0PORT TFT_VGA_G =3D VGA_OUT_GREEN > =A0PORT TFT_VGA_B =3D VGA_OUT_BLUE > END > > BEGIN plbv46_dcr_bridge > =A0PARAMETER INSTANCE =3D plbv46_dcr_bridge_0 > =A0PARAMETER HW_VER =3D 1.00.a > =A0PARAMETER C_BASEADDR =3D 0x87000000 > =A0PARAMETER C_HIGHADDR =3D 0x8700ffff > =A0BUS_INTERFACE SPLB =3D mb_plb > =A0BUS_INTERFACE MDCR =3D dcr_v29_0 > =A0PORT PLB_dcrClk =3D PLB_TO_DCR_CLK <------------- new connection > =A0PORT PLB_dcrRst =3D PLB_TO_DCR_RST <------------- new connection > END > > 3. I tried reading the memory directly from XMD and got "Debug memory > access check failed. Section, 0x87000200-0x8700203 not accessible from > processor debug interface. > I used 0x87000200 because DCR's offset is 128 (C_DCR_BASEADDR =3D > 0b0010000000) and to translate to PLB format, I multiplied by 4 as > suggested. However, I also tried other values including 0x87000080, > 0x87000100, 0x87000400, 0x87000800, 0x87001000, etc). Same result. > > It looks like the address is either not decodable or not accessible > due to misconnected ports. What do you think? If you know of any example that is using the plb to dcr bridge with microblaze, that would be very useful too. I've found only for ML401 board with opb to dcr bridge, but something is still incorrectArticle: 136338
Hello, On 12 Nov., 01:25, Jim Flanagan <jf...@tampaREMOVEbay.rr.com> wrote: > One thing (actually, many) that I don't understand: > CPLDs contain Global clock pins, sometimes 2 or more. What if > I needed several more clocks for various blocks? A SPI bus comes > to mind, must I use the GClk for this or can I define another > pin to represent the SPI sck? > > If this is true, what are the advantages of using the Global clks > pins? It depends on the technology whats happening. For most devices you can use any pin as clock, but only global clocks have dedicated buffer behaviour (each vendor might have other things optimized on such buffers) and are good when it comes to clk skew, duty cylce, delay.... In general it is always a good idea to try to avoid too much different clocks in a design. Try thinking about using a fster internal clock to catch slow external clocks. In CPLDs it is always a bit tricky because of the small amount of registers available, but you can do a design with only one master clock containing a serial interface with external clock in less than 100 FF. > Another question: > What rule of thumb tricks does one use to get an initial estimate of the > required CPLD part size (macro cells, gates) in order to satisfy > one's design? 1. Experience 2. Count registers that are really necessary (counter from 0-1023 is impossible with less than 10 FF, processing a 16 bit word serial can sometimes be done with less than 16 FF, but is very likely to need 16 registers at all) 3. add at least 10% margin even if your experienced *g* bye ThomasArticle: 136339
On Nov 11, 4:34=A0am, lomtiks...@gmail.com wrote: > On Nov 11, 1:16=A0am, sundar <sundar....@gmail.com> wrote: > > > > > On Nov 10, 3:45=A0pm, lomtiks...@gmail.com wrote: > > > > Hi, > > > > I am facing an issue of accessing the registers of a peripheral > > > sitting on the DCR bus via PLBV46 to DCR Bridge and uBlaze. The uBlaz= e > > > is on the PLB bus. The bridge is a slave on PLB and a master on DCR. > > > Please see below for a snippet of the .mhs file. > > > > Since my peripheral has the C_DCR_BASEADDR =3D 0b0000000000, I assume= it > > > is register 0 on the PLB2DCR bridge and I can simply access it by > > > looking at the base address of the PLB2DCR. For example, > > > write_adress (0x87000000, value1) > > > write_adress (0x87000004, value2) > > > Does it make sense? > > > > BEGIN plbv46_dcr_bridge > > > =A0PARAMETER INSTANCE =3D plbv46_dcr_bridge_0 > > > =A0PARAMETER HW_VER =3D 1.00.a > > > =A0PARAMETER C_BASEADDR =3D 0x87000000 > > > =A0PARAMETER C_HIGHADDR =3D 0x8700ffff > > > =A0BUS_INTERFACE SPLB =3D mb_plb > > > =A0BUS_INTERFACE MDCR =3D dcr_v29_0 > > > END > > > > BEGIN xps_tft > > > =A0PARAMETER INSTANCE =3D xps_tft_0 > > > =A0PARAMETER HW_VER =3D 1.00.a > > > =A0PARAMETER C_DCR_SPLB_SLAVE_IF =3D 0 > > > =A0PARAMETER C_TFT_INTERFACE =3D 0 > > > =A0PARAMETER C_DEFAULT_TFT_BASE_ADDR =3D 0x10800000 > > > =A0PARAMETER C_DCR_BASEADDR =3D 0b0000000000 > > > =A0PARAMETER C_DCR_HIGHADDR =3D 0b0000000011 > > > =A0BUS_INTERFACE MPLB =3D mb_plb > > > =A0BUS_INTERFACE SDCR =3D dcr_v29_0 > > > =A0PORT TFT_VSYNC =3D VGA_VSYNCH > > > =A0PORT TFT_HSYNC =3D VGA_HSYNCH > > > =A0PORT TFT_VGA_CLK =3D VGA_OUT_PIXEL_CLOCK > > > =A0PORT SYS_TFT_Clk =3D tft_clk > > > =A0PORT TFT_DE =3D VGA_OUT_BLANK_Z > > > =A0PORT DCR_Rst =3D sys_bus_reset > > > =A0PORT DCR_Clk =3D sys_clk_s > > > =A0PORT TFT_VGA_R =3D VGA_OUT_RED > > > =A0PORT TFT_VGA_G =3D VGA_OUT_GREEN > > > =A0PORT TFT_VGA_B =3D VGA_OUT_BLUE > > > END > > > > Thank you in advance > > > Hi, > > > I am not sure how your other EDK setup files looks like but still thot > > of sharing some info. > > Note: PLB can be configured as 32,63 or 128 dwidth and address access > > is by default 32. > > DCR address access is 10 width so please study address translation > > section of the Product spec. > > Now coming to direct query ....the bridge core has registers > > classified as slave access registers,interrupt registers. > > I think slave access register may not start from 0. In this case DCR > > is slave so make sure you are setting proper reg address space. > > > Hope this helps. > > > Sundar > > Thanks for your comments, Sundar. > > Following your advice, I've searched for slave access registers in > plb2dcr bridge and tft controller and have not found the restrictions. > There is a restriction for tft connected as slave on the plb bus, but > from the eng doc it looks like it is an option for PPC only. I am > using microblaze. In any case, I changed C_DCR_BASEADDR of tft > controller peripheral to from 0b0010000000 to 0b0010000011 as one of > the "ml401_emb_ref_71\projects\ml401_emb_ref" examples I found for > ml401 board (it also uses microblaze, but opb2dcr bridge and tft on > the dcr as a slave). Still I cannot change the register setting which > is supposed to change the frame buffer pointer of the tft. Note that > TFT is working fine for the default address that gets programmed with > the bitstream (I can see the picture, but I cannot change to another > memory location). > > 2. So, to debug it further, I realized that I might have misconnected > the ports on my peripheral. Previously, the xps_tft's DCR_Rst and > DCR_Clk were connected to my 100MHz sys_bus_reset and sys_clk_s > respectively and plb2dcr_bridge's PLB_dcrRst and PLB_dcrClk-- > unconnected. So now, I connected these together because from the eng > doc it looks like the PLB's clock has to clock the DCR via BUS2IP_Clk > of the =A0bridge. So my mhs file is as below now, but still I cannot > access the registers. > BEGIN xps_tft > =A0PARAMETER INSTANCE =3D xps_tft_0 > =A0PARAMETER HW_VER =3D 1.00.a > =A0PARAMETER C_DCR_SPLB_SLAVE_IF =3D 0 > =A0PARAMETER C_TFT_INTERFACE =3D 0 > =A0PARAMETER C_DEFAULT_TFT_BASE_ADDR =3D 0x10800000 > =A0PARAMETER C_DCR_BASEADDR =3D 0b0010000000 <----------changed from > 0b0000000000 > =A0PARAMETER C_DCR_HIGHADDR =3D 0b0010000011 <----------changed from > 0b0000000011 > =A0BUS_INTERFACE MPLB =3D mb_plb > =A0BUS_INTERFACE SDCR =3D dcr_v29_0 > =A0PORT TFT_VSYNC =3D VGA_VSYNCH > =A0PORT TFT_HSYNC =3D VGA_HSYNCH > =A0PORT TFT_VGA_CLK =3D VGA_OUT_PIXEL_CLOCK > =A0PORT SYS_TFT_Clk =3D tft_clk > =A0PORT TFT_DE =3D VGA_OUT_BLANK_Z > =A0PORT DCR_Rst =3D PLB_TO_DCR_RST > =A0PORT DCR_Clk =3D PLB_TO_DCR_CLK > =A0PORT TFT_VGA_R =3D VGA_OUT_RED > =A0PORT TFT_VGA_G =3D VGA_OUT_GREEN > =A0PORT TFT_VGA_B =3D VGA_OUT_BLUE > END > > BEGIN plbv46_dcr_bridge > =A0PARAMETER INSTANCE =3D plbv46_dcr_bridge_0 > =A0PARAMETER HW_VER =3D 1.00.a > =A0PARAMETER C_BASEADDR =3D 0x87000000 > =A0PARAMETER C_HIGHADDR =3D 0x8700ffff > =A0BUS_INTERFACE SPLB =3D mb_plb > =A0BUS_INTERFACE MDCR =3D dcr_v29_0 > =A0PORT PLB_dcrClk =3D PLB_TO_DCR_CLK <------------- new connection > =A0PORT PLB_dcrRst =3D PLB_TO_DCR_RST <------------- new connection > END > > 3. I tried reading the memory directly from XMD and got "Debug memory > access check failed. Section, 0x87000200-0x8700203 not accessible from > processor debug interface. > I used 0x87000200 because DCR's offset is 128 (C_DCR_BASEADDR =3D > 0b0010000000) and to translate to PLB format, I multiplied by 4 as > suggested. However, I also tried other values including 0x87000080, > 0x87000100, 0x87000400, 0x87000800, 0x87001000, etc). Same result. > > It looks like the address is either not decodable or not accessible > due to misconnected ports. What do you think? Hello, I don't know where else I find find the answer to it, but I still cannot access the registers of a device sitting on DCR bus over plb to dcr bridge. How can I check whether the bridge is alive? (I don't have chipscope) None of the peripheral's dcr registers are accessible. My main suspicion is that the Rst and Clk pins are improperly connected. Someone must have used this before. I connected PORT PLB_dcrClk and PLB_dcrRst of the bridge to DCR_Clk and DCR_Rst of the peripheral. I am sure that I am doing the proper register translation (tried both, direct and multiplication by 4 as specified by the dcr spec). ThanksArticle: 136340
Hi, I have a design which is supposed to run fine at 200mhz according to xilinx ise, but when i load the design to the fpga and try to run it at 200 mhz, it doesn't run correctly and generates false results. Behavioral simulation works correctly, and also weird thing is when i use a slower clock, fpga gives the correct results,too. Fpga is a virtex4sx35, and 100mhz clock is generated by a programmable clock chip and i use dcm to get a 200mhz clock. I am kind of a new fpga programmer and this is the first time i have seen a problem like this, usually ise gives a timing error, but this time according to ise, everything is perfect. this is the timing constraint i use: NET clka period = 10 ns; clka is fed to the dcm. Thanks.Article: 136341
["Followup-To:" header set to comp.arch.fpga.] On 2008-11-10, David Brown <david@westcontrol.removethisbit.com> wrote: > I'd like to see something like that too. The only one I can think of is > Atmel's FPSLIC's, which are an FPGA with an AVR core. But they don't > really do the same thing - the AVR core is like an add-on hard-core in a > small FPGA. I'd prefer something that had the convenience and easy of > use of a normal AVR device (or similar small micro), but with some > programmable logic built-in to off-load the processor for fast I/O or > calculation acceleration. A hundred or so CPLD macrocells would be > enough for many situations. You might be interested in PSoC. I don't know much about this but from the marketing material I've read it might have roughly the functionality you want (even though it doesn't really have an embedded CPLD or FPGA). /AndreasArticle: 136342
o0o0ozd@gmail.com wrote:
> Hi,
> I have a design which is supposed to run fine at 200mhz according to
> xilinx ise, but when i load the design to the fpga and try to run it
> at 200 mhz, it doesn't run correctly and generates false results.
Which report are you looking at? XST gives a maximum clock speed
estimate after synthesis, something like this:
"Timing Summary:
---------------
Speed Grade: -4
Minimum period: 3.781ns (Maximum Frequency: 264.480MHz)
Minimum input arrival time before clock: 1.269ns
Maximum output required time after clock: 5.531ns
Maximum combinational path delay: No path found"
This is only a guess because it doesn't take into account the routing
delays (it can't, because at this point the design hasn't been routed yet).
What you need to look at is the post place and route report. There
should be a list of all timing constraints in your design there (the one
you manually entered and there should be an auto-generated one for the
2x clock out of the DCM) and if they have been met. Something like this:
"------------------------------------------------------------------------------------------------------
Constraint | Check | Worst Case |
Best Case | Timing | Timing
| | Slack |
Achievable | Errors | Score
------------------------------------------------------------------------------------------------------
TS_clk = PERIOD TIMEGRP "plk" 6 ns HIGH | SETUP | 0.600ns|
5.400ns| 0| 0
50% | HOLD | 3.076ns|
| 0| 0
------------------------------------------------------------------------------------------------------
All constraints were met."
If this report also says the 200Mhz-constraint is met, then it should
work in reality as well.
The only other potential problem I can think of is that there are timing
problems in the interface to the outside world. If you don't use the
flipflops inside the IOBs for inputting and outputting data, the delays
from the final flipflop to the IO-pin can be quite large and are not
taken into account for timing analysis unless you specify
OFFSET-constraints for the IO-signals. So it could be that the design
inside the FPGA is running fine, but the transfer from/to the outside
world is the problem.
I suggest you set the "Pack I/O Registers Into IOBs" option to "Yes" in
the synthesis settings ("Xilinx Specific Settings" section, you might
have to switch the view to "Advanced" to see it) and see if that changes
anything.
HTH,
Sean
--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...
Article: 136343
On Nov 12, 11:55=A0am, Sean Durkin <news_no...@tuxroot.de> wrote:
> o0o0...@gmail.com wrote:
> > Hi,
> > I have a design which is supposed to run fine at 200mhz according to
> > xilinx ise, but when i load the design to the fpga and try to run it
> > at 200 mhz, it doesn't run correctly and generates false results.
>
> Which report are you looking at? XST gives a maximum clock speed
> estimate after synthesis, something like this:
>
> "Timing Summary:
> ---------------
> Speed Grade: -4
>
> =A0 =A0Minimum period: 3.781ns (Maximum Frequency: 264.480MHz)
> =A0 =A0Minimum input arrival time before clock: 1.269ns
> =A0 =A0Maximum output required time after clock: 5.531ns
> =A0 =A0Maximum combinational path delay: No path found"
>
> This is only a guess because it doesn't take into account the routing
> delays (it can't, because at this point the design hasn't been routed yet=
).
>
> What you need to look at is the post place and route report. There
> should be a list of all timing constraints in your design there (the one
> you manually entered and there should be an auto-generated one for the
> 2x clock out of the DCM) and if they have been met. Something like this:
>
> "------------------------------------------------------------------------=
------------------------------
> =A0 Constraint =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0| =A0Check =A0| Worst Case |
> Best Case | Timing | =A0 Timing
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 | =A0 =A0Slack =A0 |
> Achievable | Errors | =A0 =A0Score
> -------------------------------------------------------------------------=
-----------------------------
> =A0 TS_clk =3D PERIOD TIMEGRP "plk" 6 ns HIGH =A0 | SETUP =A0 | =A0 =A0 0=
.600ns|
> =A05.400ns| =A0 =A0 =A0 0| =A0 =A0 =A0 =A0 =A0 0
> =A0 =A050% =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0| HOLD =A0 =A0| =A0 =A0 3.076ns|
> =A0 =A0 =A0 =A0 | =A0 =A0 =A0 0| =A0 =A0 =A0 =A0 =A0 0
> -------------------------------------------------------------------------=
-----------------------------
>
> All constraints were met."
>
> If this report also says the 200Mhz-constraint is met, then it should
> work in reality as well.
>
> The only other potential problem I can think of is that there are timing
> problems in the interface to the outside world. If you don't use the
> flipflops inside the IOBs for inputting and outputting data, the delays
> from the final flipflop to the IO-pin can be quite large and are not
> taken into account for timing analysis unless you specify
> OFFSET-constraints for the IO-signals. So it could be that the design
> inside the FPGA is running fine, but the transfer from/to the outside
> world is the problem.
>
> I suggest you set the "Pack I/O Registers Into IOBs" option to "Yes" in
> the synthesis settings ("Xilinx Specific Settings" section, you might
> have to switch the view to "Advanced" to see it) and see if that changes
> anything.
>
> HTH,
> Sean
>
> --
> My email address is only valid until the end of the month.
> Try figuring out what the address is going to be after that...
thank you for your reply.
I am looking at the post place and route report.
PERIOD analysis for net "Inst_dcm4/CLK2X_BUF" derived from NET
"Inst_dcm4/CLKIN_IBUFG_OUT" PERIOD =3D 10 ns HIGH 50%
Best Case Achievable 4.999 ns.
and I will still check the IOB option but I use another clock(pci
clock) to transfer the data. Basically, I have a tree-search algorithm
which has to run fast(200mhz) and i have another slow algorithm which
transfers the result through pci. I have a 2-ff synchronizers in
between. Data is 128-bit long and i use 32-bit registers to send it.
Design works at 100mhz, used to work at 150mhz when the logic was
smaller. Bits in the middle change faster than the bits at the both
ends of the 128-bit number, and these middle bits are the wrong ones.
I have nothing so any comment,hint, reply is appreciated.
Article: 136344o0o0ozd@gmail.com wrote: > and I will still check the IOB option but I use another clock(pci > clock) to transfer the data. Basically, I have a tree-search algorithm > which has to run fast(200mhz) and i have another slow algorithm which > transfers the result through pci. I have a 2-ff synchronizers in > between. Data is 128-bit long and i use 32-bit registers to send it. > Design works at 100mhz, used to work at 150mhz when the logic was > smaller. Bits in the middle change faster than the bits at the both > ends of the 128-bit number, and these middle bits are the wrong ones. > I have nothing so any comment,hint, reply is appreciated. I'd suggest using an asynchronous FIFO for this. A synchronizer with two flipflops ist fine for single control signals (at least most of the time, but even then there's a whole lot of things to consider), but data busses should be handled differently. The easiest method is just using a FIFO, you can generate one that fits your needs with CoreGen and instantiate it in your design. So what I'd use is is a FIFO that you write to with 200MHz and read out with 33MHz (or whatever your PCI clock is). You may need a little extra logic (like a small state machine or something like that) to check the control signals (FIFO full/empty and such), but it's not really a big deal and a this is certainly a "clean" solution. Downside is you need a few BRAMs, depending on how deep the FIFO needs to be. But you can just generate one with CoreGen and how many it needs. HTH, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 136345
Hi - I was using this Bluespec for one of the FPGA implementations. Havent done the implementation yet, so no comments on that. The question is why people use Bluespec rather than Verilog. Bluespec coding takes quite more time, more complex with the syntax, the rules and functions (though very useful). One thing I didnt like was the multiple firing of variables. Please comment on how better Bluespec is.Article: 136346
Andreas Ehliar wrote: > ["Followup-To:" header set to comp.arch.fpga.] > On 2008-11-10, David Brown <david@westcontrol.removethisbit.com> wrote: >> I'd like to see something like that too. The only one I can think of is >> Atmel's FPSLIC's, which are an FPGA with an AVR core. But they don't >> really do the same thing - the AVR core is like an add-on hard-core in a >> small FPGA. I'd prefer something that had the convenience and easy of >> use of a normal AVR device (or similar small micro), but with some >> programmable logic built-in to off-load the processor for fast I/O or >> calculation acceleration. A hundred or so CPLD macrocells would be >> enough for many situations. > > You might be interested in PSoC. I don't know much about this but from > the marketing material I've read it might have roughly the functionality > you want (even though it doesn't really have an embedded CPLD or FPGA). > > /Andreas (Please don't set followup-to headers unless you really have a good reason for it - this thread is equally at home in both c.a.f. and c.a.e.) The PSoC is certainly an interesting architecture. I haven't used them, so I am basing my opinion on reading datasheets and application notes rather than experience - I hope I'll be corrected if I'm wrong here. The PSoCs digital blocks are very limited - they are basically glorified 8-bit timer/counters with internal connections to other blocks (the AVR XMega have this too). There are also *far* too few digital blocks - 4 8-bit timer/counters is not much, especially as a 16-bit timer takes two blocks, as does a full-duplex uart channel (with no extra buffering). I am also not too impressed by the cpu core. The analogue blocks are more exciting - there are not many alternative ways to get that sort of flexibility. I think if you view the PSoC devices as configurable analogue input/output devices, in which the digital blocks and the cpu are simply there to enhance the analogue blocks, then it becomes a more interesting device.Article: 136347
On Tue, 11 Nov 2008 06:40:59 -0800 (PST), John Adair <g1@enterpoint.co.uk> wrote: >Schematics and pin constraints files are now available from Polmaddie1 >product page http://www.enterpoint.co.uk/cpld_boards/polmaddie1.html. > >Pricing information has also been added to the engineering webpage and >these boards are now fully available. The product is also now in our >shop but currently miss-spelled and miss-sectioned but is on discount >for anyone that can find it there. Stock indication is also wrong on >the shop currently but that should be sorted out within the next few >hours. Looks good! I am disappointed, however, that the Polmaddie2 has neither a coin slot nor a cup dispenser. However, I expect these are in the works. - BrianArticle: 136348
On Tue, 04 Nov 2008 01:42:02 +0000, Brian Drummond <brian_drummond@btconnect.com> wrote: >... and I have seen *some* evidence that there *may* be a problem with >pipeline delays implemented as variables (actually a variable array, to >easily control the length); or the transition between signals and such >delays. About a year ago, on XST 7.1. > >It manifested as a cycle difference between the length of the pipeline >in simulation, and the same pipeline in practice. > >I didn't have time to dig down properly and locate the problem; it's >still on the ToDo list. Hence the cautious language; I regard it as most >probably something dumb on my part unless I can clearly point to XST (as >with signals in procedures obeying variable assignment scheduling). Followup: the same code (fiddled to work on ISE 7.1) gave incorrect results on 10.1. Undoing the fiddle (i.e. restoring to code which gave correct results under simulation), 10.1 synthesis also gave correct results. My conclusion: it does look like incorrect synthesis from 7.1 (and possibly other old XST versions) but it has clearly been fixed in 10.1, so I believe any further effort on this case is a waste of time. - BrianArticle: 136349
David Brown <david@westcontrol.removethisbit.com> writes: > > The analogue blocks are more exciting - there are not many alternative > ways to get that sort of flexibility. I think if you view the PSoC > devices as configurable analogue input/output devices, in which the > digital blocks and the cpu are simply there to enhance the analogue > blocks, then it becomes a more interesting device. The analogue blocks are pretty good, if a bit slow. The whole thing eats power like 74S was back in fashion, in our experience :-) Also, the smallest package sizes are massively under-resourced in terms of blocks available. 2-4 times as many and it would be a really useful item... -- rich walker | Shadow Robot Company | rw@shadowrobot.com technical director 251 Liverpool Road | skype: rich_at_shadow need a Hand? London N1 1LX | +44 20 7700 2487 http://www.shadowrobot.com/hand/
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