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
hi Andy, Generating of dual block ram with coregen is able to have a different bus width ( port b a multple of port a). The good thing is that it come with the block ram, no clb needed(? from the report, sure hope I am right). I do understand how to create logic to have different bus width on each port. but since it is free with block ram, there is not reason not to use it. But I can't find any documentation that confirmed the memory access from each port? thanks spyngArticle: 34076
Rick, Win98 supports multiple different (as in different models or vendors) display adapters. WinNT generally does not; however, a Matrox G400 dual-head works fine with one caveat -- both monitors must be set to the same resolution. This meant that my notion of using my 15" monitor and my 17" monitor at different resolutions didn't work. Matrox says that this is an NT problem, and not a problem with their card. Note that the G400 has one controller chip, which can drive either or both outputs. The Matrox people tell me that on Win2K, the G400 has the same problem (the OS thinks it's one controller chip and therefore must run both monitors at the same resolution). However, Win2K will do different resolutions on different cards, or different resolutions if the card has two controller chips. Regarding where the dialogs pop up, the Matrox driver lets you select where that happens. As a bonus, the driver seems rock-solid. -andy Rick Collins wrote: > > "Keith R. Williams" wrote: > > I'm a well known AMD fan, but wouldn't give up the bells and whistles > > on this A21p for anything. In particular, the 1600x1200 LCD display. > > I also have a graphics card in a docking station and run a secondary > > 20" display (combined 3200x1200 desktop). I can keep all of the > > ModelSim windows, along with my synthesis tools/VHDL editor open on the > > LCD and move the ModelSim waveform window to fill the entire secondary > > display. Of course, I don't haul the secondary display around with me. > > ;-) > > > > ---- > > Keith > > Is this secondary display something that Windows supports natively? Or > does it require special drivers? This would be a BIG advantage of using > a secondary graphics card. I assume that I could do this in my desktop > as well, right? > > Just out of curiosity, when a dialog box pops up that is in the center > of the display, does it pop up to the center of the TWO screens, or the > center of the first screen? > > I am also surprised that a 1600, 15" display is readable. Aren't the > fonts and icons rather small on the laptop display? But then again, I am > getting my first pair of bifocals and have been hurting to read the > newspaper for the last 6 months or so. That may be skewing my perception > of what is readable... :) > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 34077
The nice thing about... Dual port RAM is that you can do width conversion. See Table 2-10 in Chapter 2 of the handbook. Austin spyng wrote: > hi all, > I have a question regarding dual port ram with different data width. > > I have a dual port ram configure as > port A 1024x13 > port b 512x26 > > so how are the memory access from both side. > > port a : addr[0] = [12:0] of data b location 0 > port a: addr[1] = [25:13] of data b location 0 > .. > .. > port a: addr[1022] = [12:0] of data b location 511 > port a : addr[1023 = [25:0] of data b location 511 > > is this rigth? > any one know where is this in the virtex 2 manual? > > thank > spyngArticle: 34078
spyng wrote: > hi all, > I have a question regarding dual port ram with different data width. > > I have a dual port ram configure as > port A 1024x13 > port b 512x26 > > so how are the memory access from both side. > > any one know where is this in the virtex 2 manual? If you got the latest DataSource CDROM, take a look at the "Virtex-II Platform FPGA User Guide", which is also a document named ug002.pdf. It has a section on "Using Block SelectRAM Memory", and that has a table called "Port Address Mapping" with this information. I would imagine this document is also available on the Xilinx web site somewhere. -- My real email is akamail.com@dclark (or something like that).Article: 34079
"Andy Peters > Martin, > > I've found that the easiest way to do this is to AND all of the unused > inputs together, and drive the result out a spare pin. > > It's brute force, but it works. And I don't have to remember which > silly synth/P+R switch to use... > > -andy > > " ... and you probably want to give it some magic name so you don't get continual complaints from the board people about an unconnected output. I always include the string ``placeholder'' somewhere in the port name.Article: 34080
Austin Lesea wrote: > The nice thing about... > > Dual port RAM is that you can do width conversion. > > See Table 2-10 in Chapter 2 of the handbook. > > Austin > Just started using it & its great. Just one minor quibble: It would be nice if it were dynamically switchable (one for the V3 list ?). On an entirely different note: Now that V2 is out are we likely to be seeing Spartan2-E aka cheap VirtexE ?Article: 34081
One of the best features of the BRAM is that the two ports DO NOT have to be the same width. There are many applications where you want to do rate conversion, and one of the common ways is with changing the width of the data. i.e. Data arrives at 100MHz, byte wide, and is passed on to the next section 32 bits wide at 25MHz. Since these are real dual port memories, the clocks for the A and B ports can be different, so the ports can even be in different clock domains. Normal domain crossing issues still apply. Could also be used in a serial to parallel to serial conversion scheme, since you can set a port to 1 bit wide. This lets you combine SerDes functions with buffer/FIFO functions in the same block. As for the original question, the mapping of where the data goes, this is documented on page 117 of "Virtex-II Platform FPGA User Guide" which is document ug002.pdf at http://www.xilinx.com/products/virtex/handbook/ug002.pdf (it's 11.5 MBs) or just get the section you need: http://www.xilinx.com/products/virtex/handbook/ug002_ch2_blockram.pdf (300 KB) For other docs, see http://www.xilinx.com/products/virtex/handbook/index.htm On Mon, 13 Aug 2001 18:06:00 GMT, "Andy Peters <andy [@] exponentmedia" <".> com"> wrote: >I would imagine that the ports need to be the same width, and of course >your memory depth will be the same on both ends. > >If you need to, for whatever reason (and I've needed to, actually), have >the memories "look" different on each side, you'll have to design some >logic to make it do so. > >-andy > >spyng wrote: >> >> hi all, >> I have a question regarding dual port ram with different data width. >> >> I have a dual port ram configure as >> port A 1024x13 >> port b 512x26 >> >> so how are the memory access from both side. >> >> port a : addr[0] = [12:0] of data b location 0 >> port a: addr[1] = [25:13] of data b location 0 >> .. >> >> port a: addr[1022] = [12:0] of data b location 511 >> port a : addr[1023 = [25:0] of data b location 511 >> >> is this rigth? >> any one know where is this in the virtex 2 manual? >> >> thank >> spyng Philip Freidin FliptronicsArticle: 34082
Why would you want to flip the width under logic control? How would you deal with the "unused" bits after flip? Austin Rick Filipkiewicz wrote: > Austin Lesea wrote: > > > The nice thing about... > > > > Dual port RAM is that you can do width conversion. > > > > See Table 2-10 in Chapter 2 of the handbook. > > > > Austin > > > > Just started using it & its great. Just one minor quibble: It would be > nice if it were dynamically switchable (one for the V3 list ?). > > On an entirely different note: Now that V2 is out are we likely to be > seeing Spartan2-E aka cheap VirtexE ?Article: 34083
I finally remembered the name of one of the companies selling pci adapters supporting multiple displays. See Colorgraphics at http://www.colorgfx.comArticle: 34084
The book is based on an Altera product. But I wasn't sure if this is a specific feature of the MAX+PLUS II development tool or some generic library that can also be used in the Xilinx Foundation tools. I guess I could just rewrite a new memory interface that works the same using VHDL. But it would be nice to know if I could still use the "lpm" library in Xilinx Foundation... Mark > "lpm" sounds like "altera" to me but you are using a xilinx tool. > > utku > >Article: 34085
Well after further searching on the internet I was able to find a site that seems to be the maintainers of the LPM library. And at the following URL http://www.edif.org/lpmweb/more/vhdl.htm they have a downloadable VHDL library for the LPM library. I will try this and see if it works with Xilinx Foundation. MarkArticle: 34086
spyng wrote: > >so how are the memory access from both side. > >port a : addr[0] = [12:0] of data b location 0 >port a: addr[1] = [25:13] of data b location 0 >.. >.. >port a: addr[1022] = [12:0] of data b location 511 >port a : addr[1023 = [25:0] of data b location 511 > For a COREGEN created dual port blockram, if you still have version 1.0 of the COREGEN dual port RAM datasheet (COREGEN 2.1i), see figure 6 for a nice picture showing where all the bits go from each port (note the little-endian mapping of the narrow port data to the wider port). Unfortunately, that very useful diagram isn't in the latest version of the COREGEN datasheet. If you can use the COREGEN blockram, by all means do so, as it hides the gory details of a variable-width block ram memory that spans multiple block ram's. ----------------------------------------------------------- If you can't use the COREGEN memory, make sure you understand where all the bits go before you slap together your own version from the primitives... When you spread the data across multiple DP block RAM's, it's very important to realize that word N on the wide side, as created by concatenating the outputs of each block RAM sequentially, is composed of interspersed bit fragments of words M, M+1, etc., from the narrow side. This makes for some interesting bit indexing to reassemble the memory words, and also makes it impossible to do byte writes from the wider port. I posted some notes on this (for Spartan-II) a while back at: http://groups.yahoo.com/group/fpga-cpu/message/234 "How NOT to build variable width dual port Block RAMs" Summary from this post: (pertaining to a "roll your own" 512x32/1Kx16) " 1) If a variable width dual-port block RAM spans more than one block RAM, the output bits of the wider port need shuffling to assemble the proper output data word, beyond the usual big-endian vs. little-endian swaps. 2) If you need byte write enables on the RAM, you can't use the variable width dual port feature. ( If you can live with word writes on the wider port, you're OK. ) 3) To use byte write enables, both ports need to be at the same port width ( 8 bits or narrower ). COREGEN notes: I looked at the coregen EDIF output for a 1Kx16 / 512x32 block RAM; it does the output bit shuffling for you, but always builds a little-endian output word on the wider port. Also, it doesn't allow for byte write enables, which is why I didn't use COREGEN in the first place. " BrianArticle: 34087
Hi all, hamish@cloud.net.au wrote: > The original poster said he had design components which depended on > shared sub-components, and that different components might use different > versions of the same sub-components. I'm not sure how any version control > system would cope with that; you can only expect to see one version of > any particular entity at one time. I might even go so far as to say > that it sounds like a bad idea to need this feature. I think multiple versions at the same time are a common problem, so a version control system should provide such mechanismen We use SCCS with version numbering (1.1, 1.2,...). Each release gets a new major version number, so a Design might use e.g. any Files with version 3.1. And its no problem to use multiple versions in different directories The only problem I see is to have multiple versions of the same file in the same directory. bye Thomas -- Thomas Stanka Bosch SatCom GmbH UC_RA/EMD4 s/UC-RA/BC Gerberstr. 49 Tel. +49 7191 930-1690 Zi. 10/528 Fax. +49 7191 930-21690 Thomas.Stanka@de.bosch.comArticle: 34088
pete dudley wrote: > My experience is with the Xilinx floorplanners and chip editors that allow > you to view and control everything. Does anyone have experience with the > floorplanner/chip editor tools for Actel or Quicklogic? Is it possible to > gain fine control of these architectures through source constraints or > floorplanning? Actel provides a tool that should work for you ;) If necessary, you're able to set every cell and every pin by hand. You could also mark a set of cells an drag them anywhere you want. bye Thomas -- Thomas Stanka Bosch SatCom GmbH UC_RA/EMD4 s/UC-RA/BC Gerberstr. 49 Tel. +49 7191 930-1690 Zi. 10/528 Fax. +49 7191 930-21690 Thomas.Stanka@de.bosch.comArticle: 34089
Austin Lesea wrote: > Why would you want to flip the width under logic control? > > How would you deal with the "unused" bits after flip? > > Austin > > Rick Filipkiewicz wrote: > > > I have a situation where one set of BRAMs lie between memory & the PCI.. I'd like to be able to build a single device which can handle any combination of 64/32-bit DRAM & 64/32-bit PCI. Clearly for economy reasons the packaging might change but that would then just (?) be a question of running the flow again from MAP ->. So its not very ``dynamic'' in that it's not required to vary cycle-by-cycle but more a run-time option.Article: 34090
hamish@cloud.net.au wrote: > Rick Collins <spamgoeshere4@yahoo.com> wrote: > > Clearcase also makes it hard to do some things such as using labels to > > track builds. > > Really? Just an extra line in the config spec for your view. > I agree with Allan.. ClearCase is overkill for most FPGA work (it > excels for the software engineers), but it's nice overkill to have. > With project teams of 2-7 FPGA engineers, we use labels and branches > with good effect. We don't usually need to do much merging though. > The GUI integration is IMHO really good, but you do have to use > the command line for non-day-to-day stuff. > > The original poster said he had design components which depended on > shared sub-components, and that different components might use different > versions of the same sub-components. I'm not sure how any version control > system would cope with that; you can only expect to see one version of > any particular entity at one time. I might even go so far as to say > that it sounds like a bad idea to need this feature. We could envisage having this feature so that, say, a number of chips use a given library element. If I change that element for a particular reason for one chip, I then build that chip test it on the bench and if I'm happy ... I release and save it as an updated version. I also release and save the library element. So, at that point chip X uses v1.4 of library elemtn P, and chips Y and Z use v1.3 of the same library element. It's then up to the owners of Y and Z to decide whether they want/need to re-build their chips given that a common component has just changed. It could be the case that a change was minor, and as the build for chip Z takes 1 week (minor design changes in xilinx can cause big changes in netlist) then the owner decides it's not worth updating Z. Further on this topic ... does CC and PCVS handle the versioning of whole directories instead of purely just files? Gary Cook. Sony Oxford.Article: 34091
On Tue, 14 Aug 2001 09:08:44 +0100, Gary Cook <gc@sonyoxford.co.uk> wrote: >hamish@cloud.net.au wrote: > >> Rick Collins <spamgoeshere4@yahoo.com> wrote: >> > Clearcase also makes it hard to do some things such as using labels to >> > track builds. >> >> Really? Just an extra line in the config spec for your view. >> I agree with Allan.. ClearCase is overkill for most FPGA work (it >> excels for the software engineers), but it's nice overkill to have. >> With project teams of 2-7 FPGA engineers, we use labels and branches >> with good effect. We don't usually need to do much merging though. >> The GUI integration is IMHO really good, but you do have to use >> the command line for non-day-to-day stuff. >> >> The original poster said he had design components which depended on >> shared sub-components, and that different components might use different >> versions of the same sub-components. I'm not sure how any version control >> system would cope with that; you can only expect to see one version of >> any particular entity at one time. I might even go so far as to say >> that it sounds like a bad idea to need this feature. > >We could envisage having this feature so that, say, a number of >chips use a given library element. If I change that element for a >particular reason for one chip, I then build that chip test it on the >bench and if I'm happy ... I release and save it as an updated version. >I also release and save the library element. So, at that point chip X >uses v1.4 of library elemtn P, and chips Y and Z use v1.3 of the >same library element. It's then up to the owners of Y and Z to decide >whether they want/need to re-build their chips given that a common >component has just changed. > >It could be the case that a change was minor, and as the build for >chip Z takes 1 week (minor design changes in xilinx can cause big >changes in netlist) then the owner decides it's not worth updating Z. > >Further on this topic ... does CC and PCVS handle the versioning >of whole directories instead of purely just files? I know clearcase does. This can lead to some interesting configuration problems. Say user1 creates a file in their branch of a directory. User2 creates a similarly named, but different file in their branch of the same directory. Now try to merge the branches. Which file gets picked up by the merged directory? Most of the time the directory thing works really well though. Allan.Article: 34092
Dear all, I want to install the xilinx 3.3i ISE under winme platform. After the successful installation and re-boot the computer, I can't find the project navigator in the programs file on the start up menu. Also I cannot find this file on the xilinx directory. Also I have added the path on the autoexec.bat file , it still not work too. So can you give some suggestions to me to overcome this problem. Thank you very muchArticle: 34093
Allan, Allan Herriman wrote: > On Tue, 14 Aug 2001 09:08:44 +0100, Gary Cook <gc@sonyoxford.co.uk> > wrote: > ...snip.. > > > > >Further on this topic ... does CC and PCVS handle the versioning > >of whole directories instead of purely just files? > > I know clearcase does. > > This can lead to some interesting configuration problems. Say user1 > creates a file in their branch of a directory. User2 creates a > similarly named, but different file in their branch of the same > directory. > > Now try to merge the branches. Which file gets picked up by the > merged directory? > > Most of the time the directory thing works really well though. > > Allan. thanks for the info. We already use CC here for s/w and so are going to try and setup a simple trial environment to see if CC looks promising. As for merging ... I think we are going to try and avoid situations that require merging as much as possible!! Cheers, Gary.Article: 34094
Hello All, I am looking for reasonably priced development boards that use FPGAs. The boards should be for application development and not for testing purposes. They should use the PCI bus interface in a PC. I am not interested in going into the details of programming the PCI interface if an FPGA is used for that purpose. It is preferable to have parts of the PCB board available for in-house circuit additions also. Memory subsytem is not very important on the board. Any help with knowledge of availability of such boards, vendor addresses, web pointers, prices etc will be greatly appreciated. Thank you. AliArticle: 34095
Hi, I have a little question about containing my SpartanII design that uses DLLs and some signals that should be constrained against a simple clock and some against the doubled clock. Here ist the VHDL code for the DLL section: I_dll_int : CLKDLL port map( clkin => LCLK, clkfb => clklocal, locked => dll_locked_int, rst => reset, clk2x => clk2x_prebuf, clk0 => clk1x_prebuf ); local : BUFG port map ( I => clk1x_prebuf, O => clklocal ); double : BUFG port map ( I => clk2x_prebuf, O => clkdouble ); I_dll_zbt : CLKDLL port map ( clkin => LCLK, clkfb => MEM_CLK5, locked => dll_locked_ext, rst => reset, clk2x => MEM_CLK ); "I_dll_int" and "local" and "double" are used to generate clklocal and clkdouble for use inside the FPGA. since LCLK is feed with 33MHz, clkdouble should have 66MHz. ... This is working ! Next, "I_dll_zbt" is a DLL that doubles LCLK to 66MHZ, but the feedback loop is external, since this clock is used by some ZBT synchronous SRAMs. All signals in capitals are FPGA pins. How do I have to constrain the control, address and data signals for my ZBT RAMs ? My 33MHZ clock input has a period constraint in the .ucf file. This seems to be right. NET "lclk" PERIOD = 30ns; I figured out that I can constrain the BUFG as well, but not for the doubled clock. Why ? Why not ? #NET "double" PERIOD = 15ns; NET "local" PERIOD = 30ns; I have seen the following lines in an example. I get errors because "local" does not exist any more in the implementation. Why ? Is it essential ? #NET "double" TNM=c2x; #NET "local" TNM=c1x; #TIMESPEC TS10= FROM: c2x: TO: c1x: 15ns; #TIMESPEC TS11= FROM: c1x: TO: c2x: 15ns; This is my real problem ! How can I constain my zbt RAMs datalines against the doubled clock (MEM_CLK) ? The only thing that runs through without errors is the following (using LCLK and not MEM_CLK). NET mem_d<*> OFFSET = IN : 7 : AFTER : lclk; NET mem_d<*> OFFSET = OUT : 7.5 : BEFORE : lclk; What do I have to change to contain mem_d<*> against MEM_CLK ? The complete memory controller is clocked by the internal clock "clkdouble". Any advice would be very nice ! Matthias -- -------------------------------------------------------------------------- _/_/_/_/ _/_/_/_/ _/_/_/_/ matthias.fuchs@esd-electronics.com _/_/_/ _/_/_/_/_/_/_/ esd electronic system design gmbh _/ _/ _/ _/ Vahrenwalder Str. 205 _/ _/ _/_/_/ _/ _/ D-30165 Hannover _/ _/ _/ _/ Phone: +49-511-37298-0 _/_/_/_/_/_/_/ _/_/_/ Fax: +49-511-37298-68 --------------------------------------------------------------------------Article: 34096
I am looking for a vendor that develop synthesizable VHDL floating point add, subtract, multiply and divide for Xilinx FPGA. Thanks Khoi HaArticle: 34097
I need to redesign some older MAX Pals from ALTERA. I would like to use the old DOS Version (V 3.71, 28.2.1991) MAXPLUS. Can I download this software from some place or does anybody have it and would like to sell it ? Many thanks, FelixArticle: 34098
thanks all, I found the docs in ug002.pdf. (I was looking at the data sheet for V2 and block ram :( and they are not there) and run a sim, it work as I have expected. just cursious, so the block ram can be see as a 18K x 1 bit memory, and if I have a data width of 13. it is going to pack the data in [12:0], [25:13], [38:26] ...... and not as a 16 bit block, and have the last 3 bit ignore? thanks spyng brimdavis@aol.com (BriMDavis) wrote in message news:<20010813225155.01553.00000107@mb-ci.aol.com>... > spyng wrote: > > > >so how are the memory access from both side. > > > >port a : addr[0] = [12:0] of data b location 0 > >port a: addr[1] = [25:13] of data b location 0 > >.. > >.. > >port a: addr[1022] = [12:0] of data b location 511 > >port a : addr[1023 = [25:0] of data b location 511 > > > For a COREGEN created dual port blockram, if you still have > version 1.0 of the COREGEN dual port RAM datasheet (COREGEN 2.1i), > see figure 6 for a nice picture showing where all the bits go > from each port (note the little-endian mapping of the narrow port > data to the wider port). Unfortunately, that very useful diagram > isn't in the latest version of the COREGEN datasheet. > > If you can use the COREGEN blockram, by all means do so, as it > hides the gory details of a variable-width block ram memory > that spans multiple block ram's. > > ----------------------------------------------------------- > > If you can't use the COREGEN memory, make sure you understand > where all the bits go before you slap together your own version > from the primitives... > > When you spread the data across multiple DP block RAM's, it's very > important to realize that word N on the wide side, as created by > concatenating the outputs of each block RAM sequentially, is > composed of interspersed bit fragments of words M, M+1, etc., > from the narrow side. > > This makes for some interesting bit indexing to reassemble the > memory words, and also makes it impossible to do byte writes > from the wider port. > > I posted some notes on this (for Spartan-II) a while back at: > > http://groups.yahoo.com/group/fpga-cpu/message/234 > "How NOT to build variable width dual port Block RAMs" > > > Summary from this post: > (pertaining to a "roll your own" 512x32/1Kx16) > " > 1) If a variable width dual-port block RAM spans more > than one block RAM, the output bits of the wider port > need shuffling to assemble the proper output data word, > beyond the usual big-endian vs. little-endian swaps. > > 2) If you need byte write enables on the RAM, you can't > use the variable width dual port feature. ( If you can > live with word writes on the wider port, you're OK. ) > > 3) To use byte write enables, both ports need to be at > the same port width ( 8 bits or narrower ). > > COREGEN notes: > I looked at the coregen EDIF output for a 1Kx16 / 512x32 > block RAM; it does the output bit shuffling for you, but > always builds a little-endian output word on the wider port. > > Also, it doesn't allow for byte write enables, which is why > I didn't use COREGEN in the first place. > " > > BrianArticle: 34099
I had a ME related problem a while ago (look back for some archive material - Xilinx solution 9253 was most appropriate). Basically, it was a problem with the path. Be careful how you attempt to modify the autoexec.bat file. You have to use the system utilities to modifiy, not just a text editor on the autoexec.bat files. There's registry issues involved. I've now got a problem with the ModelSim package not finding the design. Oh well... -- Paul T. "jimmy" <jimmy_siu_@hongkong.com> wrote in message news:9lat2j$o7l7@imsp212.netvigator.com... > Dear all, > I want to install the xilinx 3.3i ISE under winme platform. After the > successful installation and re-boot the computer, I can't find the project > navigator in the programs file on the start up menu. Also I cannot find this > file on the xilinx directory. Also I have added the path on the autoexec.bat > file , it still not work too. > So can you give some suggestions to me to overcome this problem. > Thank you very much > >
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