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
Peter Alfke wrote: > Not externally, but inside the SRL there is (I think) a clock > differentiator. The idea is to put a low-pass filter between adjacent > latches, and make the transfer pulse so short, that the transfer is > only of the old, stable dta, not of the just arriving data. That avoids > any race condition. The conventional master-slave flip-flop uses a more > brute-force approach that requires two latches. > The "low-pass filter, clock differentator" approach was popular 50 > years ago, when discrete transistors were expensive, and resistors and > capacitors were cheap. I thought most modern LOGIC devices FlipFlips, were built using transmission gates - which I think is what you are talking about with the SRL's ? eg my classic 74LVC74 data, shows 4 OR gates, and 4 transmission gates. -jgArticle: 97926
Thanks to all for your help. The most important requirement of the board is that it must have a non-volatile memory so I can power-off it on the night (when there isn't thr sun that recharge the battery via solar panel), thus I'm oriented to the XCR board (that also don't cost so much). ByeArticle: 97927
Is this PCI card plugged into the same system that you are running the download program on? If so... Don't do that. The card will kill the bus during a program cycle, and take the host machine down.Article: 97928
Jim, modern CMOS master slave flip-flops use transmission gates to form the latches, and a shift register relies on the two latches to avoid the race condition (enabling alternate latches at alternate times.) The SRL16 is a modifiction of the basic LUT-RAM, where there are only 16 latches. So the only way to make a 16-bit shift register was to invent a substitute for the master latch. Pretty clever1 Peter Alfke Jim Granville wrote: > Peter Alfke wrote: > > Not externally, but inside the SRL there is (I think) a clock > > differentiator. The idea is to put a low-pass filter between adjacent > > latches, and make the transfer pulse so short, that the transfer is > > only of the old, stable dta, not of the just arriving data. That avoids > > any race condition. The conventional master-slave flip-flop uses a more > > brute-force approach that requires two latches. > > The "low-pass filter, clock differentator" approach was popular 50 > > years ago, when discrete transistors were expensive, and resistors and > > capacitors were cheap. > > I thought most modern LOGIC devices FlipFlips, were built using > transmission gates - which I think is what you are talking about with > the SRL's ? > eg my classic 74LVC74 data, shows 4 OR gates, and 4 transmission gates. > > -jgArticle: 97929
<sharp@cadence.com> wrote in message news:1141235829.504003.89220@z34g2000cwc.googlegroups.com... > Presumably this depends on what ASIC libraries you have. There is no > inherent reason that an ASIC library could not include dual-port > memories. Apparently the original poster's didn't. > True, some TSMC ASIC libraries had dual-read/write memories, and they used to provide memory generators which enables creating the memory blocks of any capacity. After we changed foundry, things got really complicated. In the new library, only a few memories are provided and the width & depth are also fixed. It becomes very inefficient to use these RAMs. I guess I am out of luck on memory issues this time.Article: 97930
<sharp@cadence.com> wrote in message news:1141236232.823214.283550@j33g2000cwa.googlegroups.com... > That is a clever solution that I hadn't thought of. Of course, your > VALID_BIT array needs the capabilities of a true dual-port memory. So > this doesn't really build a dual-port memory just out of RAMs. It > builds it from 4 RAMs and a smaller dual-port memory (just as many > elements, but only 1 bit wide). You would have to build that smaller > dual-port memory out of flip-flops. The result still might be smaller > than building the full-size memory out of flip-flops. > Morning Samuelsson & sharp, I haven't got time to study the sequence of the clever solution yet. I want to know is, does it have the function of a full dual port R/W RAM if the R/W accesses of both ports are random? My RAM is 130*6bit, and the IP uses eight pieces of this RAM. TIAArticle: 97931
hi!
i want to know that i2c addressing scheme for page write
fashion how will it be.
i mean what will be
address scheme.
Article: 97932Yes, Ulf's solution gives full dual-port functionality for arbitrary addresses (though of course you have to decide which port gets the last word in case of simultaneous writes to the same address, as with any dual-port memory). But with your small word size of 6 bits, this may not be cost-effective. The VALID_BIT array requires similar logic to a 1-bit-wide dual-port memory (not quite the same, since port 0 always writes a value of 0 and port 1 always writes a value of 1). So you have to design something close to a 130*1bit dual-port memory out of flip-flops and logic, and use that with four 130*6bit RAMs (or two 130*6bit dual-read/single-write RAMs, since you indicated you have those). You might be as well off to design a 130*6bit dual-port memory from flip-flops and logic.Article: 97933
Hello Mich, The master IPIF has a slave IPIF attachment, which interacts with master IPIF accesses. It is important to understand how it operates because the master won't function. For instance, for a: Master Read -- Assert IP2Bus_MstReq. You'll see that the read data returns through the slave attachment, appearing like a write-request to your "local target memory" (some register or BRAM inside your pcore) with Bus2IP_WrReq going high and Bus2IP_WrCE[x] as well (if you chose to use CEs). For proper functionality, you have to acknowledge this slave-attachment write with a IP2Bus_WrAck. Then, you will receive Bus2IP_MstRdAck some cycles later to confirm that your master read has been completed by the master IPIF. At this point, you can de-assert IP2Bus_MstRdReq. Master Write -- Raise IP2Bus_MstWrReq. The slave attachment will respond saying that it is ready to "read" your write data by asserting Bus2IP_RdReq (and Bus2IP_RdCE[x] if you have enabled CE's in IPIF). Once you have your write data ready, you issue IP2Bus_RdAck, which tells the slave attachment to read the data and push it to the master IPIF. Once the master IPIF is done writing the data, you'll receive Bus2IP_MstWrAck, at which point you can de-assert IP2Bus_MstWrReq. Pretty confusing if you ask me...but that's what is provided.... Good luck! NN Mich wrote: > Hi > > I 'm also trying to use a master ip on the PLB bus and I also use the > IPIF interface from the "Create Peripheral" wizard in EDK's XPS. > Like you I have some troubels with writhing and reading (I want to > write and read to/from a BRAM on the PLB-Bus) > You say that the slave attachment is also used for the master > trasaction. When I look at the timing diagram on pg 116 of the > plb_ipif.pdf > (http://www.xilinx.com/bvdocs/ipcenter/data_sheet/plb_ipif.pdf) it say > that when you read you will get a Bus2IP_WrReq is this correct, because > you want to read and not write. Is this correct? > > I have made a small FSM to test a single read and write (at the bottom > of the message is my VHDL-code) > > I have a state (PrepareWr_State and PrepareRd_State) to make sure all > the addresses are correct > I have a state (ReqWr_State and ReqRd_State) for the request => > IP2Bus_MstWrReq and IP2Bus_MstRdReq > I have a state (AckWr_State and AckRd_State) for the ack that the IPIF > can read/write from/to my ip => IP2Bus_WrAck and IP2Bus_RdAck > I have a state (OkWr_State and OkRd_State) so I know everything went > well > > But there must be something wrong because it doesn't work, when I want > to write something, my FSM stays in the ReqWr_State, and when I want to > read something it also doesn't do what it should do (or atleast what I > think it should do) > > Can you help me please? > > Mich > > > > -- TRANSITION_STATE_LOGIC > > STATE_TRANSITION_LOGIC: process (ACTUAL_STATE, pushR, pushL, pushU, > pushD, Bus2IP_MstLastAck, Bus2IP_WrReq, Bus2IP_RdReq) > variable counter_Rd : integer range 0 to 15; > variable counter_Wr : integer range 0 to 15; > begin > > case ACTUAL_STATE is > when idle => > if (pushR = '0') then -- pushR is active low > NEXT_STATE <= PrepareWr_State; > counter_Wr := 10; > elsif (pushL = '0') then -- pushL is actief laag > NEXT_STATE <= PrepareRd_State; > counter_Rd := 10; > else > NEXT_STATE <= idle; > end if; > > when PrepareWr_State => > if (counter_Wr = 0) then > NEXT_STATE <= ReqWr_State; > else > NEXT_STATE <= PrepareWr_State; > counter_Wr := counter_Wr - 1; > end if; > > when ReqWr_State => > if (Bus2IP_MstLastAck = '1') then > NEXT_STATE <= AckWr_State; > else > NEXT_STATE <= ReqWr_State; > end if; > > when AckWr_State => > if (Bus2IP_MstLastAck = '1') then > NEXT_STATE <= OkWr_State; > else > NEXT_STATE <= AckWr_State; > end if; > > when OkWr_State => -- Writing is ok > if (pushU = '0') then -- PusU is active Low > NEXT_STATE <= idle; > else > NEXT_STATE <= OkWr_State; > end if; > > when PrepareRd_State => > if (counter_Rd = 0) then > NEXT_STATE <= ReqRd_State; > else > NEXT_STATE <= PrepareRd_State; > counter_Rd := counter_Rd - 1; > end if; > > when ReqRd_State => > if (Bus2IP_WrReq = '1') then > NEXT_STATE <= AckRd_State; > else > NEXT_STATE <= ReqRd_State; > end if; > > when AckRd_State => > if (Bus2IP_MstLastAck = '1') then > NEXT_STATE <= OkRd_State; > else > NEXT_STATE <= AckRd_State; > end if; > > when OkRd_State => -- Reading is ok > if (pushD = '0') then -- pushD is actief laag > NEXT_STATE <= idle; > else > NEXT_STATE <= OkRd_State; > end if; > > when others => NEXT_STATE <= idle; > end case; > > end process STATE_TRANSITION_LOGIC; > -- TRANSITION_STATE_LOGIC > > -- OUTPUT_LOGIC > OUTPUT_LOGIC: process (ACTUAL_STATE) > begin > case ACTUAL_STATE is > when idle => > led <= "1110"; > IP2Bus_Data(0 to 3) <= schakelaar; > IP2Bus_RdAck <= '0'; > IP2Bus_WrAck <= '0'; > IP2Bus_Addr <= C_Memory_Addr; > IP2Bus_MstBE <= "11111111"; > IP2Bus_MstRdReq <= '0'; > IP2Bus_MstWrReq <= '0'; > > when PrepareWr_State => > led <= "0001"; > IP2Bus_Data(0 to 3) <= D_out; > IP2Bus_RdAck <= '0'; > IP2Bus_WrAck <= '0'; > IP2Bus_Addr <= C_Memory_Addr; > IP2Bus_MstBE <= "11111111"; > IP2Bus_MstRdReq <= '0'; > IP2Bus_MstWrReq <= '0'; > > when ReqWr_State => > led <= "0010"; > IP2Bus_Data(0 to 3) <= D_out; > IP2Bus_RdAck <= '0'; > IP2Bus_WrAck <= '0'; > IP2Bus_Addr <= C_Memory_Addr; > IP2Bus_MstBE <= "11111111"; > IP2Bus_MstRdReq <= '0'; > IP2Bus_MstWrReq <= '1'; > > when AckWr_State => > led <= "0011"; > IP2Bus_Data(0 to 3) <= D_out; > IP2Bus_RdAck <= '1'; > IP2Bus_WrAck <= '0'; > IP2Bus_Addr <= C_Memory_Addr; > IP2Bus_MstBE <= "11111111"; > IP2Bus_MstRdReq <= '0'; > IP2Bus_MstWrReq <= '1'; > > when OkWr_State => > led <= "0100"; > IP2Bus_Data(0 to 3) <= schakelaar; > IP2Bus_RdAck <= '0'; > IP2Bus_WrAck <= '0'; > IP2Bus_Addr <= C_Memory_Addr; > IP2Bus_MstBE <= "11111111"; > IP2Bus_MstRdReq <= '0'; > IP2Bus_MstWrReq <= '0'; > > when PrepareRd_State => > led <= "1000"; > IP2Bus_Data(0 to 3) <= D_out; > IP2Bus_RdAck <= '0'; > IP2Bus_WrAck <= '0'; > IP2Bus_Addr <= C_Memory_Addr; > IP2Bus_MstBE <= "11111111"; > IP2Bus_MstRdReq <= '0'; > IP2Bus_MstWrReq <= '0'; > > when ReqRd_State => > led <= "1001"; > IP2Bus_Data(0 to 3) <= D_out; > IP2Bus_RdAck <= '0'; > IP2Bus_WrAck <= '0'; > IP2Bus_Addr <= C_Memory_Addr; > IP2Bus_MstBE <= "11111111"; > IP2Bus_MstRdReq <= '1'; > IP2Bus_MstWrReq <= '0'; > > when AckRd_State => > led <= "1010"; > IP2Bus_Data(0 to 3) <= D_out; > IP2Bus_RdAck <= '0'; > IP2Bus_WrAck <= '1'; > IP2Bus_Addr <= C_Memory_Addr; > IP2Bus_MstBE <= "11111111"; > IP2Bus_MstRdReq <= '1'; > IP2Bus_MstWrReq <= '0'; > > when OkRd_State => > if (D_out = Bus2IP_Data(0 to 3)) then > led <= "1011"; > else > led <= "1100"; > end if; > IP2Bus_Data(0 to 3) <= schakelaar; > IP2Bus_RdAck <= '0'; > IP2Bus_WrAck <= '0'; > IP2Bus_Addr <= C_Memory_Addr; > IP2Bus_MstBE <= "11111111"; > IP2Bus_MstRdReq <= '0'; > IP2Bus_MstWrReq <= '0'; > > when others => > led <= "1111"; > IP2Bus_Data(0 to 3) <= schakelaar; > IP2Bus_RdAck <= '0'; > IP2Bus_WrAck <= '0'; > IP2Bus_Addr <= C_Memory_Addr; > IP2Bus_MstBE <= "00000000"; > IP2Bus_MstRdReq <= '0'; > IP2Bus_MstWrReq <= '0'; > end case; > > end process OUTPUT_LOGIC; > -- OUTPUT_LOGICArticle: 97934
Thanks for that nice tidbit. There has been a dream that reconfigurable computing using FPGA's as computing engines for quite some time, and as it seems fostered this news group some time ago. Would be interesting to dig out the archives and see what the topics for this group where for the first year. I have to admit, that I'm a new comer, only taking up the dream some five or so years back, but very hopeful at this point. "At first, dreams seem impossible, then improbable, and eventually inevitable." Christopher Reeve Writing an example PCI bus interface this week in FpgaC has been something of an eye opener for me ... feels just like writing device drivers again :) Diddling (creating) the "hardware registers" for the PCI bus interface in FpgaC really isn't that different than many other low level device drivers I've written for 30 years. I'm pretty certain as we train other device driver and embedded guys in this, they will feel the same way about C and FPGAs. My target is 64bit at 66mhz for the XCV2000E-8's on the Dini DN2K boards I have. First try with ISE PAR was pretty horrible, as even with high effort selected, it was stumbling again with horrible placement choices with less than 1% of the device in use - not even 33 Mhz performance. Hacking on Mike Dini's fpga-f usf file to get the pin assignments to match his board and going thru route/place again last night, missed the 66mhz timing budget by about 2% on the second try. Placement for some variables used at the top of the pci process created some longer combinatorial chains than I had expected. Placing them at the bottom of the function will remove the deep combinatorials, and leave that path much shorter from the registered version of the variables. I spent some time in FPGA-Editor again last night, just to discover the pin locking in the ucf file brought the logic down near the bottom of the chip and near the pads, but ISE 6.1i par failed horribly to do a best effort set of assignments WITH NOTHING in the way. Clearly excessive routing incurred do to poor placement. You would expect that it would at least put the LUT's driving the pads in the CLB nearest the IOB, not a half dozen away, crossing others. And then place the read LUT and FF for the PAD into the same CLB, along with the associated access logic, not scattered half way across the chip. FPGA-Editor really is the schematic design tool for Xilinx Fpga's of choice, except that it will not let you just use a slice that doesn't already have a connection. Is there some way around this, other than creating a dummy netlist to put something in each of the slices you want to use? Colin Paul Gloster wrote: >Nial Stewart replied: >> This newsgroup and FPGAs were around long before some numpty at Google >> decided what their description should be. [..] > > This has nothing to do with Google. Check your newsgroups file, the > description of this group is "Field Programmable Gate Array > based computing systems." See > WWW.SLRN.org/manual/slrn-manual-6.html#ss6.117 > or > HTTP://Quimby.Gnus.org/gnus/manual/gnus_358.html#SEC358 > or something similar.Article: 97935
Peter Alfke wrote: > Sounds like a powerful FPGA argument: > Ifyou really need a true dual-port memory (read and write from either > or both ports simultaneously), you are out-of-luck in the ASIC world, > but you can do this just fine in FPGAs. > Nice to know we have such an edge... That is completely dependent on the ASIC libraries. In FPGA you are out of luck with higer amount of ports that are available in some ASIC libraries. For example in the ASIC library I use there are: single port, 1 read 1 write, dual port and 4-port memories. And then different versions of those (density, power, speed). --KimArticle: 97936
hard_temac.pdf page 23: "The MII management interface is not implemented in this release" !!!! so that it doesnt matter what you do with mdc and mdio as the core doesnt support management interface anyway ! the connection details can be derived from temac.vhd from xapp807.zip if you want to my surprise the management clk in is set to GND! hm, maybe the Management interface is not working in xapp807 either ? AnttiArticle: 97937
just login to memec RDC and download the docs you need !Article: 97938
it is described in the datasheet of the device you are usingArticle: 97939
logjam wrote: > I soldered a PQFP144 package with one of those dull pointed radio shack > irons. Used a lot of solder flux and dragged the tip along the 4 sides > of the chip. Worked great. Out of the two chips I soldered I had one > bridge. (which I found before the smoke test ;) ) I haven't had to do > one of those in a few years, but now I have a much better solder statio > so hopefully I could do better this time. :) I've also used that for 50mil packages, but it's hard to avoid bridging with packages that have finer pitch. BGA's are cool and easy. Solder wet all the pcb bga pads with a solder ball pushed around with the pads slightly over fluxed, so there is a small shiny bump at each pad. Clean pcb, reflux, place BGA with flux covering balls on the pcb pads, and reflow in a convection oven for a few minutes. 300-1700 connections terminated with really only two minutes effort and several more cleaning and watching it bake :) > > I was thinking about a transistor based computer last night. What kind > of memory can I use in a transistor computer without cheating? Core > memory? Should I just have a goal of "transistor CPU" and consider the > ram a peripheral? > > One guy built a relay computer but used a 62256 for ram. :) Most of the early computers I worked with in Dr. Dicky's lab with tubes, were bit serial executing directly off multi-channel read/write from the drums (head per track, and several concurrent channels). It would literally be fetching instruction, data, operating on the data, and writing all at the same time. Track down the schematics for the Bendix G15 - I saw them on the web somewhere last fall. It's a tube based drum computer, but was simple, and they made a lot of them. There is probably some software kicking around for it as well. I would suggest if you wanted to build a fun transistor computer, to design it bit serial with four IDE hard drives, two of which could be crashed, as long as you could still do diagnositic read/write to it's buffer. Then the computer would just need a hand full of serial/parallel buffers at the edges for the drive interfaces. Or better yet, get some older drives that still have a serial interface, and be really retro :) Being really retro would be taking a hand full of floppy drives apart for their heads, collecting some 1" mag tape and glue to a cylinder, and building a drum. Or maybe machine up a nice drum, and have it nickle plated, for the real thing :)Article: 97940
"Derek Simmons" <dereks314@gmail.com> wrote in message news:1141230364.062159.31900@i39g2000cwa.googlegroups.com... > I've been trying to follow your problem and now have time to lend some > help. I'm going to approach this from a black-box design point of view. > > > First question is how are in implementing it or what language are you > using (VHDL, Verilog or something else)? > > What size device are you looking to create (data and address bus > width)? Or are you trying to create a library device? > > What device and signals in the original design being used? > > Derek > Thank you Derek. I received an FPGA design in RTL Verilog and need to convert into ASIC. Now everything is done except this memory issue. The design of the RTL is unfamiliar to me so large modifications are meant only for the long run. Requesting redesign of the memory isn't an option either. The culprit RAMs are 8 instances of 130*6bit DPRAM. My entire design is 200K gate without RAM. My short term goal is to use the existing RAMs in the ASIC library and perform successful synthesis & gate level simulation, with ASIC RAMs included in the system (I could simulate with Xilinx RAM and ASIC for the rest). What ideas do you have for my description?Article: 97941
"Antti" <Antti.Lukats@xilant.com> wrote in message news:1141285563.043110.41250@t39g2000cwt.googlegroups.com... > just login to memec RDC and download the docs you need ! > Thank you Antti but I don't have password for that. We dug up this board from among piles of used hardwares in the storage, everything is gone except the board itself. Can you do me a favor to login and dl the doc?Article: 97942
Brad Smallridge wrote: > XAPP709 states that a 200-MHz DDR SDRAM can be built using MIG coregen, > however, when I run mig006_rel6 ISE7.1.04, I don't see V4s on the drop down > selector. What's the story? mig007_rel6 is not "MIG coregen". The MIG you're looking for is included in CORE Generator, it's not a standalone tool. You can install it via the online updates function in CORE Generator. Last time I checked there was MIG available for ISE8.1, so this only works for the CORE Generator included in ISE7.1. cu, SeanArticle: 97943
130 by 6 is pretty tiny to have used a whole 4K or 18k bit DPRAM but the DP feature makes it a job already done. Are the 8 rams independant copies of the same DP R/W design? And 130 is a bit odd isn't it? For this size of this problem the 4 way Ulf design doesn't look so bad assuming you can compile 130 by 6 arrays, I'd imagine they will be bigger. Now you only need 130 DP flags to resolve valid words. JohnArticle: 97944
"Antti" <Antti.Lukats@xilant.com> wrote in message news:1141285512.377077.5290@e56g2000cwe.googlegroups.com... > hard_temac.pdf page 23: > > "The MII management interface is not implemented in this release" !!!! > > so that it doesnt matter what you do with mdc and mdio as the core > doesnt support management interface anyway ! > > the connection details can be derived from temac.vhd from xapp807.zip > if you want > to my surprise the management clk in is set to GND! > hm, maybe the Management interface is not working in xapp807 either ? > > Antti > I read this morning the datasheet and I discovered what you said. I don't understand why MII is supported in ll_temac core and not into hard temac. So, I think I will use ll_temac. MarcoArticle: 97945
Hi Xun, Planahead 8.1 supports partial reconfiguration in Virtex 4. Check out this recent article: http://www.us.design-reuse.com/news/news12519.html -Love http://www.ics.uci.edu/~lsinghalArticle: 97946
>The OP mentioned "motor control" so I assume that latency matters. >This might rule out the use of bit-bashing. Or the CPU might be busy doing other things, or the program storage might be full, or there might not even be a CPU, or ... -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 97947
you dont need password but the board #serial number, but I think it is printed on piece of paper and not on the board, so you are possible out of luck, I have downloaded with robot all the content of memec RDC so the pdf you are looking is also there, if you email me in private I can send it to you anttiArticle: 97948
> Last time I checked there was MIG available for ISE8.1, > so this only works for the CORE Generator included in ISE7.1. Just checked again: There now is MIG 1.5 for ISE8.1 available. cu, SeanArticle: 97949
Hi, I am having problems trying to get an Aurora core working in Virtex 4 parts. Has anyone managed to get an MGT working in Virtex4? I am using Aurora 2.4 and just trying to do a simple loopback between 2 MGTs. I can't get CHANNEL_UP to assert in the Aurora cores and the MGT is showing RXBUFERR indicating an RX FIFO underflow/overflow? I have followed all the clocking recommendations in the MGT User Guide. Any thoughts? Thanks Dave.
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