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 Mar 27, 8:48 am, Jim Lewis <j...@synthworks.com> wrote:
> Andy
>
> > I think Synopsys has problems with not knowing the type of the
> > expression (A'range => ASel). Other vendors seem to be able to figure
> > it out, but I've never tracked down whether it is legal per LRM.
>
> Formally when you run into a situation where one tool accepts code
> and another does not, you enter a bug (interpretation) request to
> VHDL's Issues Screening and Analysis Committee (ISAC) via:
> http://www.eda-stds.org/vasg/#Enhancements
>
> In this case select: Report a BUG on an IEEE VHDL revision
>
> Then ISAC will issue a response. The following is the ISAC
> resolution to the above issue (recently ISAC Approved):
> http://www.eda.org/isac/IRs-VHDL-2002/IR2097.txt
>
> > Weng, would you rather have to type all that garbage out, or just
> > write a function:
>
> > ...
> > temp := '0';
> > for i in x'range loop
> > temp := temp xor x(i);
> > end loop;
> > return temp;
>
> Note that he is calculating several parity terms (such
> as in SECDED logic) and each incorporates different, not necessarily
> contiguous pieces of the array. I also note that in my final equation,
> I had ment to give the function call a different name than XOR as you
> would not want to use the operator name in this case:
>
> y_xor(0) <= XOR_Reduce(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
> x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
> x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
> x(58), x(60), x(61), x(63) ));
>
> You can either code your own XOR_reduce or use the one from synopsys'
> package, std_logic_misc (IIRC).
>
> Cheers,
> Jim
Hi Jim,
Thank you for your response.
> Also note, in VHDL, "*" is multiply and "+" is add. Is that
> what you mean or are using it as a short hand for "and" and "or".
Yes.
> Y <= A(A'left - 1) ;
OK, XOR_Recude(A'left - 1, A'left - 2);
It doesn't change any original VHDL definitions or rules, but only add
a '...' as a unlimited input signal that means user can add any number
of input signals as required by the function to do the same operation
as designed with variable number of input signals.
Which is better:
Introduction:
AndOR(a0, b0, ...);
With this package, you can write your equations as:
R(63 downto 0) <= (a0 and b0) or (a1 and b1) or ... or
(an and bn);
In my presentation, it will become:
R(63 downto 0) <= AndOR(a0, b0, a1, b1, a2, b3, ..., an, bn);
The best thing is the AndOR function will be optimized by compiler
companies, because its definition is clear to do AND, then OR
operations on pair of input signals one pair after another.
> Write yourself a function that accepts std_logic_vector as an input and
> add an extra set of parentheses to the call:
> y_xor(0) <= XOR(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14),
> x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36),
> x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55),
> x(58), x(60), x(61), x(63) ));
What I want to introduce a new type of input signal '...' is not to
write any type of this function any more, no matter how many signals
are there, a library function can be called. It should be much better
than several functions XOR(a0, b0) that are included in some library.
If a compiler company provides a XOR_Reduce(a0, a1, ...) in its
library or VHDL standard library includes such functions, VHDL users
would never have to write it again and again. Because in this type of
function XOR_Reduce(a0, a1, ...), the number of input signals can be
varied without concerning to write an 8 input signals, 9 input signals
or others. The function XOR_Reduce(a0, a1, ...) is applied to all XOR
operators with any number of input signals. In current situations, for
function XOR(a0, a1), it has only 2 input signals, far leg behind the
real need such that I don't think XOR(a0, a1) is useful, even though
XOR operators are used widely in any projects.
Weng
Article: 117276Pete Fraser wrote: > Any suggestions? Just one: get a Platform USB Cable. Much more reliable, simply works, under Windows and Linux. I too have had nothing but trouble with Parallel Cables. After days of fiddling around with BIOS settings, trying a handfull of different PCI plug-in cards, trying a dozen different PCs, I've found that most parallel controllers in motherboard chipsets and add-on-cards only support speeds up to 1.5 MHz, if you look at their datasheets. In iMPACT, you can only select speeds of 200kHz, 2MHz and 5MHz (can't remember the actual numbers, but something along these lines), so it always drops down to 200kHz. I'm not sure, but I believe in ISE9 you can now finally set some speeds between 200kHz and 2Mhz, so it's at least a little faster. Doesn't explain, why the exaxt same card worked fine in one PC and now doesn't in another, though... Anyway, I highly recommend getting a USB cable, if you can afford it. The only problem there is that detection of the maximum possible transfer speed doesn't work reliably. Usually, iMPACT sets it too high, so you get "Invalid ID code returned from device"-errors or something and have to manually select a slower speed. 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: 117277
Mr Tianxiang, Your first mission needs to be to read and study a good VHDL syntax book, such as Peter Ashenden's "Designer's Guide to VHDL", on subprograms and in particular subprograms with unconstrained arrays. When all the elements are the same, such as std_logic, then a subprogram that accepts an unconstrained std_logic_vector can be used - although you need an extra set of parentheses. As shown in my example that I posted previously: >> y_xor(0) <= XOR_Reduce(( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14), >> x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36), >> x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55), >> x(58), x(60), x(61), x(63) )); Please also read my paper on Accellera VHDL standard 3.0. Read up on the unary usage of operators such as XOR. Unfortunately due to overloading it will need a type qualifier, but you will be able to use it as: >> y_xor(0) <= XOR std_logic_vector'( x(1), x(2), x(3), x(5), x(8), x(9), x(11), x(14), >> x(17), x(18), x(19), x(21), x(24), x(25), x(27), x(30), x(32), x(36), >> x(38), x(39), x(42), x(44), x(45), x(47), x(48), x(52), x(54), x(55), >> x(58), x(60), x(61), x(63) ); > AndOR(a0, b0, ...); To use a similar technique, the repeated arguments would need to be part of a record and then you would need an array of the record. The call syntax would be: AndOr ( ((a0, b0), (a1, b1), (a2, b2), ... ) ) ; Personally I would not go to this trouble as I expect that synthesis vendors do very well on And-Or type logic. > If a compiler company provides a XOR_Reduce(a0, a1, ...) Did you look for the package I suggested existed (std_logic_misc (IIRC))? Don't get too attached to it as like I noted, XOR will be able to handle this functionality in the future. Cheers, Jim Lewis SynthWorks VHDL TrainingArticle: 117278
"Sean Durkin" <news_mar07@durkin.de> wrote in message news:56t9c1F29u138U1@mid.individual.net... > Pete Fraser wrote: >> Any suggestions? > Just one: get a Platform USB Cable. Much more reliable, simply works, > under Windows and Linux. Thanks Sean. I am going to borrow a USB cable, and if it works I'll buy one. I had just hoped I could get the cable I have already to work, but it seems like USB is the way to go. I remember a few years ago folks were complaining about the USB cable, but it seems like it's solid now.Article: 117279
Mikhail, Right now the core I am working with is the Embedded Tri-mode Ethernet MAC Wrapper 4.4 from in the current version of CORE Generator. I am not trying to use EDK at the moment to keep things easier to manage since I am not as familiar with EDK as I am with ISE. >On Mar 22, 7:34 pm, "MM" <m...@yahoo.com> wrote: > Mark, > > Which core exactly are you talking about? I have successfully used ll_temac > EDK core, although I had to tweak it somewhat to implement RGMII interface. > This might be already done in the latest revision though. Also, my design > was based on the GSRD reference design. > > /Mikhail > > <mwiesb...@gmail.com> wrote in message > > news:1174600404.051325.276560@p15g2000hsd.googlegroups.com... > > > Here are a few more details about the project of getting this core up > > and running: > > > Using the GMII Interface, in trimode > > I am trying to keep this project inside of ISE , and not use EDK for > > anything at the moment. > > The only changed I made to the UCF so far would be the LOC assignments > > of the RX/TX Signals and with the IDELAYCTRL location. I am still > > looking more into the IDELAYCTRL location that I should be using since > > this part is still pretty new to me and I haven't done much work with > > constraints past basic pin assignment. > > > As well, if anyone know any good sites that go over the constraints > > used in these UCF files, please let me know. I do already know about > > Xilinx's scattered PDF files on their site which for me at least do > > not always tend to be that clear, so anything other than those (such > > as some .edu site with lab handouts, etc) would be great! > > > Thanks again, > > -MarkArticle: 117280
On Mar 27, 11:14 am, "radarman" <jsham...@gmail.com> wrote: > I did bring both signals out on test points, and I can see this > behavior on a scope. The interrupt performs as expected, but once the > WDT_Reset signal goes high, it stays high until I reconfigure the > FPGA. Why don't you copy C:\EDK81/hw/XilinxProcessorIPLib/pcores/ opb_timebase_wdt_v1_00_a to your local pcores directory and modify timebase_wdt_core.vhd to do what you want it to do? Alan NishiokaArticle: 117281
On Mar 23, 12:25 pm, "Jim Wu" <jimwu88NOOOS...@yahoo.com> wrote: > On Mar 22, 5:53 pm, mwiesb...@gmail.com wrote: > > > > > Here are a few more details about the project of getting this core up > > and running: > > > Using the GMII Interface, in trimode > > I am trying to keep this project inside of ISE , and not use EDK for > > anything at the moment. > > The only changed I made to the UCF so far would be the LOC assignments > > of the RX/TX Signals and with the IDELAYCTRL location. I am still > > looking more into the IDELAYCTRL location that I should be using since > > this part is still pretty new to me and I haven't done much work with > > constraints past basic pin assignment. > > > As well, if anyone know any good sites that go over the constraints > > used in these UCF files, please let me know. I do already know about > > Xilinx's scattered PDF files on their site which for me at least do > > not always tend to be that clear, so anything other than those (such > > as some .edu site with lab handouts, etc) would be great! > > > Thanks again, > > -Mark > > > On Mar 22, 5:31 pm, mwiesb...@gmail.com wrote: > > > > Hello, > > > > I am trying to get the Virtex-4 Ethernet MAC Wrapper IP Core up and > > > running on my Avnet Virtex-4 FX12 Mini Module (http://tinyurl.com/ > > > yqc6ah), and I am having all sorts of problems. One of the main > > > problems right now seems to be my understanding of the UCF file and > > > what to edit or not to edit, since the rest of the design should be > > > already set up fine from what I have read in the user guide. > > > > I am trying to run the example design that was generated,so that I may > > > send the board a packet and it send me one back to make sure > > > everything is working correctly, but so far no luck. > > > > Has anyone used this ip core before with some successes , no matter > > > what version? Please let me know if so... it would be greatly > > > appreciated! > > > > -Mark > > > (I can post or upload as many details/files as requested, but I didnt > > > want to just spam all that stuff up here on the first post) > > I have used the Coregen TEMAC core in several designs. The generated > files include the LOC for IDELAYCTRL in the source code, so I would > recommend you remove that first. .e.g. my vhdl wrapper > temac_v3_2_block.vhd has the line below. You can either comment it out > or remove it completely. > attribute loc of dlyctrl : label is "IDELAYCTRL_X2Y1"; > > If you don't care about the IDELAYCTRL replication, you don't even LOC > it in UCF. If you really want to know which pins are associated with > which IDELAYCTRL, you can use ADEPT to view that (http:// > home.comcast.net/~jimwu88/tools/adept/): load the device and click > View->Show IDELAYCTRL). > > The other thing you may need to play with is the delay on gmii_rx_clk. > You can change it (IOBDELAY_VALUE of IDELAY block) either in source > code (rx_clk_gen.v/vhd) or in UCF. > > HTH, > Jim Thanks Jim! I will go ahead and try to use your advice, as well as to use the 3.2 versions which seemed to work with your design and I will post back on what I can manage to get done. I may not be able to get back for a while since I am currently trying to get some other things finished up, but this needs to be completed soon, so I will have to be working on it shortly. As well, do you know of any sites that may use this core in an example design, such as a .edu site or the like? -MarkArticle: 117282
jonas@mit.edu wrote: > I'm working on a new project using some code from opencores for my > thesis research. I'd love to use a nice, high-quality tiny-fsm like > picoblaze or the lattice semi micro8. However, I'm worried about > licensing issues, as I'd also like to be able to use the opencores IP > and release the whole thing under the GPL. Does anyone know / have a > strong opinion on whether or not the Lattice Open IP license allows > the code to be incorporated into GPL'd designs? I pretty sure the > PicoBlaze does not allow this, and pacoblaze isn't so useful for those > of us in vhdl-land. IIRC, the picoblaze license says the core is free to use on Xilinx devices. Since Xilinx's picoblaze is built straight from instantiated primitives instead of portable HDL, Xilinx's picoblaze is completely useless on non-Xilinx devices. I have not looked at other vendors' PSMs but I suspect their licenses and possibly their code are both crafted along similar lines. Since the picoblaze's license is self-enforced by design, my guess is that you would not have any problems using the picoblaze in a GPL'd project as long as you do not slap the GPL onto picoblaze sources or alter/remove the existing license. I have contemplated writing my own plain VHDL picoblaze to add a few small features like a 16 entries stack and variable forward jump/call for a while now but then I'd have to put together my own compiler or be stuck having to massage the binaries between builds. (Well, I looked at pacoblaze's homepage and it seems like it already has some of the features I am interested in along with a java-based open-source compiler... maybe I'll translate that to VHDL and tweak the compiler to support my own extras and altered features.)Article: 117283
On Mar 25, 6:19 pm, psihode...@googlemail.com wrote: > Many engineers today have Linux on Desktop as main-OS. Many engineers > today use Open Source products because of their quality, stability, > and configurability. > > Today I see no alternative to use Xilinx or Alteras Web Packs. Both > are in a very sad state. As Linux or PowerPC user you cannot develop > your FPGA design with this tools. On x86 or on Windows they are very > buggy, slow, and unproductive as well. > > So, any idea, how can we change this situation? Will we meet the time > of Open Source development tools for programmable logic devices? Here we go again ... =aArticle: 117284
Antti wrote: > JTAG BPI S3E issue - there is a solution that fixes the problem > the external flash memory can be put into status read mode using > CFI commands and boundary scan, then the JTAG can be used to > work with the FPGA as if there S3e bug wasnt there. Its a bit tricky > but working solution. We did implement your suggested work-around and it works great! Much better than the Xilinx suggested workarounds. Thanks Antti! I have also be intermittently chasing this issue through Xilinx. I finally got an answer today. They confirmed that this problem does still exist in stepping 1. They have decided not to fix this problem in hardware (since their first attempt failed), but rather make a software change. The latest version of iMPACT has this fixed, ISE 9.1.01i. (Our JTAG guy does think that their software fix is sound, although we have not tried it in our software). They have an answer in their database, 22255, which gives more detail on this problem. I opened this case over six months ago, and they were able to reproduce the problem, yet they still have not publicly acknowledged that this problem still exists with stepping 1. In fact, they still state that it does not exist in stepping 1. Wrong information is worse than no information! The datasheet says: "Stepping 1 and later devices fully support JTAG configuration even when the FPGA mode pins are set for BPI mode." and answer 22142 says: "NOTE: This issue applies to only Spartan-3E engineering samples and to the Stepping 0 devices. This is not an issue for Stepping 1 devices." Granted, this is a small problem that likely doesn't affect many people, but it is totally unacceptable that they do not have an adequate process for fixing their documentation, even when a customer goes out of their way to try to help them fix it! Through our Avnet FAE (who has been very helpful) I was finally able to get them to issue a CR to fix their datasheet, today, March 27, 2007. Case opened August 23, 2006. Datasheet fixed sometime April 2007? Great response time! I hope others haven't wasted time with this in the interim. Jason Daughenbaugh http://www.advanced.proArticle: 117285
On Mar 27, 12:06 am, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote: > Back then, I used schematics only to avoid having to code boring top-level > VHDL port maps... but the frequent crashes and other annoyances (like zero > portability) quickly convinced me that I would be better off wrapping > everything up in VHDL. emacs VHDL mode to the rescue. oh, yeah, it's open source. > An extra semicolumn at the wrong place can crash XST but these are often > hard to spot since any other programming language would silently accept > them. I take it that you don't simulate much, if at all ... > Over the last two or three years, I wasted over a month hunting down > syntax-induced crashes, about a week of it last summer because XST got > confused while processing BRAM inferences... it took me a few days to > figure out the link between crashes and memory inferences and many more > tweaking the inference until I got what I wanted without crashing XST or MAP. > > The last time I ran into simple syntax errors I was unable to spot within > 2-3 minutes, I simply ran the thing through ModelSim's compiler... both a > fair bit faster and much more reliable. you should have used ModelSim FIRST ! -aArticle: 117286
Daniel S. wrote: > jonas@mit.edu wrote: > >> I'm working on a new project using some code from opencores for my >> thesis research. I'd love to use a nice, high-quality tiny-fsm like >> picoblaze or the lattice semi micro8. However, I'm worried about >> licensing issues, as I'd also like to be able to use the opencores IP >> and release the whole thing under the GPL. Does anyone know / have a >> strong opinion on whether or not the Lattice Open IP license allows >> the code to be incorporated into GPL'd designs? I pretty sure the >> PicoBlaze does not allow this, and pacoblaze isn't so useful for those >> of us in vhdl-land. > > > IIRC, the picoblaze license says the core is free to use on Xilinx > devices. Since Xilinx's picoblaze is built straight from instantiated > primitives instead of portable HDL, Xilinx's picoblaze is completely > useless on non-Xilinx devices. I have not looked at other vendors' PSMs > but I suspect their licenses and possibly their code are both crafted > along similar lines. > > Since the picoblaze's license is self-enforced by design, my guess is > that you would not have any problems using the picoblaze in a GPL'd > project as long as you do not slap the GPL onto picoblaze sources or > alter/remove the existing license. > > I have contemplated writing my own plain VHDL picoblaze to add a few > small features like a 16 entries stack and variable forward jump/call > for a while now but then I'd have to put together my own compiler or be > stuck having to massage the binaries between builds. (Well, I looked at > pacoblaze's homepage and it seems like it already has some of the > features I am interested in along with a java-based open-source > compiler... maybe I'll translate that to VHDL and tweak the compiler to > support my own extras and altered features.) Also, the Mico8 is quite similar to PicoBlaze, so you could try modifying that lineage ? Lattice have an assembler (opensource) - but last time I looked, it was pretty annoyingly basic, but Alfred Arnold added the Mico8 to his AS Assembler (open source), which is quite a lot better. -jgArticle: 117287
Hi, When I am turning to Xilinx Virtex-5 new chips from Virtex-II, I would like to know which patents filed by Xilinx to disclose the contents of Slice L. Slice M is too complex for me to fully understand at the moment and just knowledge of Slice L is good enough for me to start with Virtex-5 as basic knowledge for it. Thank you. WengArticle: 117288
Is page 158 of the Virtex-5 User Guide http://direct.xilinx.com/bvdocs/userguides/ug190.pdf just too darned simple for you? Are you trying to understand the operation of the part from the detailed silicon level tricks that may or may not be applicable for this part of the device? I tried looking at a DDR IOB cell patent once and found it to be interestingly disconnected from my RTL and chip level design experience. If you are into physical level design of CMOS chips on advanced processes you have a chance of understanding how things come together. If all you want to know is how that chip will work for you, use the User's Guide! I don't have to know about the metal casting used for the alternator in my car to understand how the alternator works. You don't need patents to understand the SLICE_L. - John_H "Weng Tianxiang" <wtxwtx@gmail.com> wrote in message news:1175036266.831589.180920@b75g2000hsg.googlegroups.com... > Hi, > When I am turning to Xilinx Virtex-5 new chips from Virtex-II, I would > like to know which patents filed by Xilinx to disclose the contents of > Slice L. > > Slice M is too complex for me to fully understand at the moment and > just knowledge of Slice L is good enough for me to start with Virtex-5 > as basic knowledge for it. > > Thank you. > > WengArticle: 117289
Lattice is holding a webcast Tomorrow Wednesday, Mar 28, "Tips for FPGA Timing Closure." The presenter will be Troy Scott, from our software marketing group. Please attend or pass along this invitation to attend by registering at: http://www.latticesemi.com/corporate/webcasts/tipsforfpgatimingclosure/index.cfm Regards, Bart Borosky Lattice SemiconductorArticle: 117290
"Jim Lewis" <jim@synthworks.com> wrote in message news:130it10cdc7ocbf@corp.supernews.com... > Mr Tianxiang, Mr. Jim, I wonder, should it be Mr. Weng? Perhaps, given his manifest interest in languages, the Mr. OP can instruct us on the correct etiquette? Cheers, Mr. Syms. http://en.wikipedia.org/wiki/Chinese_nameArticle: 117291
On Mar 27, 3:25 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > Is page 158 of the Virtex-5 User Guide > > http://direct.xilinx.com/bvdocs/userguides/ug190.pdf > > just too darned simple for you? Are you trying to understand the operation > of the part from the detailed silicon level tricks that may or may not be > applicable for this part of the device? I tried looking at a DDR IOB cell > patent once and found it to be interestingly disconnected from my RTL and > chip level design experience. If you are into physical level design of CMOS > chips on advanced processes you have a chance of understanding how things > come together. If all you want to know is how that chip will work for you, > use the User's Guide! > > I don't have to know about the metal casting used for the alternator in my > car to understand how the alternator works. You don't need patents to > understand the SLICE_L. > > - John_H > > "Weng Tianxiang" <wtx...@gmail.com> wrote in message > > news:1175036266.831589.180920@b75g2000hsg.googlegroups.com... > > > > > Hi, > > When I am turning to Xilinx Virtex-5 new chips from Virtex-II, I would > > like to know which patents filed by Xilinx to disclose the contents of > > Slice L. > > > Slice M is too complex for me to fully understand at the moment and > > just knowledge of Slice L is good enough for me to start with Virtex-5 > > as basic knowledge for it. > > > Thank you. > > > Weng- Hide quoted text - > > - Show quoted text - Hi John, Yes, I am interested in ASIC design of Slice L and want someone's help to locate the patent filed by Xilinx that contains the contents of Slice L. I am not interested in slice M that is too complex to me now. I have already printed the user manual you indicated and carefully read it. But it doesn't meet my curiority. WengArticle: 117292
hi all i am mahalingam, student from univ of south florida. i am using xilinx ise 8.1 and virtex ii pro 2vp30 board for my design. i would like to get the edk 8.1 tool and some directions in installing the same. i tried xilinx website and downloaded some update, which dosent seem to work/ do i need to buy this or is it available for evaluation for academic customers. thanks very much. sincerely, mahalingamArticle: 117293
Weng, you seem to believe that there is a one-to-one corresponcence between the content of a patent and the Xilinx implementation. That is not necessarily so. If you want to learn what a certain company is interested in, then looking at patents is meaningful, (but you still suffer from the 2- to-4year delay in patent issuing.) If you want to design an ASIC, intimate knowledge of the FPGA may be more hindrance than help. The architecture and circuit trade-offs are completely different. Keep studying... Peter Alfke ========================== On Mar 27, 6:10 pm, "Weng Tianxiang" <wtx...@gmail.com> wrote: > On Mar 27, 3:25 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > > > > > Is page 158 of the Virtex-5 User Guide > > > http://direct.xilinx.com/bvdocs/userguides/ug190.pdf > > > just too darned simple for you? Are you trying to understand the operation > > of the part from the detailed silicon level tricks that may or may not be > > applicable for this part of the device? I tried looking at a DDR IOB cell > > patent once and found it to be interestingly disconnected from my RTL and > > chip level design experience. If you are into physical level design of CMOS > > chips on advanced processes you have a chance of understanding how things > > come together. If all you want to know is how that chip will work for you, > > use the User's Guide! > > > I don't have to know about the metal casting used for the alternator in my > > car to understand how the alternator works. You don't need patents to > > understand the SLICE_L. > > > - John_H > > > "Weng Tianxiang" <wtx...@gmail.com> wrote in message > > >news:1175036266.831589.180920@b75g2000hsg.googlegroups.com... > > > > Hi, > > > When I am turning to Xilinx Virtex-5 new chips from Virtex-II, I would > > > like to know which patents filed by Xilinx to disclose the contents of > > > Slice L. > > > > Slice M is too complex for me to fully understand at the moment and > > > just knowledge of Slice L is good enough for me to start with Virtex-5 > > > as basic knowledge for it. > > > > Thank you. > > > > Weng- Hide quoted text - > > > - Show quoted text - > > Hi John, > Yes, I am interested in ASIC design of Slice L and want someone's help > to locate the patent filed by Xilinx that contains the contents of > Slice L. I am not interested in slice M that is too complex to me now. > > I have already printed the user manual you indicated and carefully > read it. But it doesn't meet my curiority. > > WengArticle: 117294
On Mar 20, 8:28 am, John_H <newsgr...@johnhandwork.com> wrote: > dlharmon wrote: > > I am getting a warning on 18 and 36 bit wide block rams inferred in my > > Verilog code in ISE 9.1. The following code is an example of what > > causes the warning. I do not get warnings on 16 or 32 bit wide > > blockrams inferred this way. The resulting block rams do not work > > properly when loaded into an FPGA. > > > module bramtest(din, dout, ain, aout, wr, clk); > > input [17:0] din; > > output [17:0] dout; > > reg [17:0] dout; > > input [9:0] ain, aout; > > input wr, clk; > > reg [17:0] bram_test[0:1023]; > > always @ (posedge clk) > > begin > > if(wr) > > bram_test[ain] <= din; > > dout <= bram_test[aout]; > > end // always @ (posedge clk) > > endmodule // bramtest > > > (From map report) > > > WARNING:PhysDesignRules:1060 - Dangling pins on > > block:<Mram_bram_test/Mram_bram_test.A>:<RAMB16_RAMB16A>. The > > block is > > configured to use input parity pins. There are dangling output > > parity pins. > > > I would appreciate any suggestions. I would really like to stick with > > the inferred memory, but may consider using alternative methods. > > > Thanks for your help > > > Darrell Harmon > > I've seen this harmless warning for way too long though I often get it > for instantiated BlockRAMs where I don't actually read the parity bits > but I write them with zero values so the port isn't undefined. > > It's possible the complaint is because the write port is written with > parity bits but the write port output parity bits are unused. Who cares? > > I'd suggest you take a look at the FPGA Editor (or some other technology > view) to see if all your pins are hooked up properly. If your design > truly does not work - as opposed to being a coding/debug problem which > it often is for my development - then there is something wrong with the > synthesis which has to be addressed by the vendor. I often infer > memories with SynplifyPro but haven't used XST for any development. > > I'd love to see the warning actually mean something but I've lost any > confidence that it's communicating anything real because of my past > experience with it. > > - John_H Thanks to everyone for the help. I did take a look with FPGA Editor and everything is getting connected correctly. It appears that it is just yet another spurious warning as some of you suggested. I had the input signal connected to a scrambled version in another clock domain of the intended signal connected to the DDC input, causing output to be seemingly random. Darrell HarmonArticle: 117295
Andy Peters wrote: > On Mar 27, 12:06 am, "Daniel S." > <digitalmastrmind_no_s...@hotmail.com> wrote: > >> Back then, I used schematics only to avoid having to code boring top-level >> VHDL port maps... but the frequent crashes and other annoyances (like zero >> portability) quickly convinced me that I would be better off wrapping >> everything up in VHDL. > > emacs VHDL mode to the rescue. > > oh, yeah, it's open source. My primary OS is WinXP... but for all my boring regexable copy-paste jobs, I started using remote-X'd Nedit sessions about a year ago. Regex replace is definitely a godsend for portmaps and batch portmap signal declaration. >> An extra semicolumn at the wrong place can crash XST but these are often >> hard to spot since any other programming language would silently accept >> them. > > I take it that you don't simulate much, if at all ... > > you should have used ModelSim FIRST ! It depends on what I am doing and why. Until my larger designs are sufficiently advanced to start producing meaningful simulation results (I call this the approximation phase), I am more interested in tracking resource utilization and static timing evolution than correctness: achieving absolute correctness in the first pass (the one most susceptible to typos and syntax errors) is useless if the implementation fails to meet target timings or exceeds the logic budget. It is during these passes that XST&all die on me the most and Modelsim as a simulation tool is irrelevant - that's why it took me so long to think of using it as a syntax checker.Article: 117296
Hi, Due to recent changes, the 2-to-4 year delay has been reduced somewhat. If you go to http://www.uspto.gov/patft/, you can now view published applications. I'm not sure how soon after filing that an application is made available to the public, but based on random searches of the patents of my colleagues it seems like it is in the neighborhood of 1 year. I agree with Peter -- rarely will you see what exactly was implemented in the chip in a patent; it is usually some combination of a bunch of patents mixed with good engineering and a dash of trade secrets. And it can be hard to tell what a patent was really about by the time it gets turned into legalize... - PaulArticle: 117297
On Mar 27, 7:15 pm, "Peter Alfke" <a...@sbcglobal.net> wrote: > Weng, you seem to believe that there is a one-to-one corresponcence > between the content of a patent and the Xilinx implementation. > That is not necessarily so. > If you want to learn what a certain company is interested in, then > looking at patents is meaningful, (but you still suffer from the 2- > to-4year delay in patent issuing.) > If you want to design an ASIC, intimate knowledge of the FPGA may be > more hindrance than help. The architecture and circuit trade-offs are > completely different. > Keep studying... > Peter Alfke > ========================== > > On Mar 27, 6:10 pm, "Weng Tianxiang" <wtx...@gmail.com> wrote: > > > > > On Mar 27, 3:25 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > > > > Is page 158 of the Virtex-5 User Guide > > > > http://direct.xilinx.com/bvdocs/userguides/ug190.pdf > > > > just too darned simple for you? Are you trying to understand the operation > > > of the part from the detailed silicon level tricks that may or may not be > > > applicable for this part of the device? I tried looking at a DDR IOB cell > > > patent once and found it to be interestingly disconnected from my RTL and > > > chip level design experience. If you are into physical level design of CMOS > > > chips on advanced processes you have a chance of understanding how things > > > come together. If all you want to know is how that chip will work for you, > > > use the User's Guide! > > > > I don't have to know about the metal casting used for the alternator in my > > > car to understand how the alternator works. You don't need patents to > > > understand the SLICE_L. > > > > - John_H > > > > "Weng Tianxiang" <wtx...@gmail.com> wrote in message > > > >news:1175036266.831589.180920@b75g2000hsg.googlegroups.com... > > > > > Hi, > > > > When I am turning to Xilinx Virtex-5 new chips from Virtex-II, I would > > > > like to know which patents filed by Xilinx to disclose the contents of > > > > Slice L. > > > > > Slice M is too complex for me to fully understand at the moment and > > > > just knowledge of Slice L is good enough for me to start with Virtex-5 > > > > as basic knowledge for it. > > > > > Thank you. > > > > > Weng- Hide quoted text - > > > > - Show quoted text - > > > Hi John, > > Yes, I am interested in ASIC design of Slice L and want someone's help > > to locate the patent filed by Xilinx that contains the contents of > > Slice L. I am not interested in slice M that is too complex to me now. > > > I have already printed the user manual you indicated and carefully > > read it. But it doesn't meet my curiority. > > > Weng- Hide quoted text - > > - Show quoted text - Hi Peter, Thank you for your advice. I like reading and learning. Your paper about asynchronous FIFO cooperated with another engineer is the best article I have read in my life. WengArticle: 117298
Hi, (this is my second attempt to get some help on the subject). I am searching for an FPGA board having multiple gigabit ethernet connectivity support on it. To be more precise, I need to have multiple RJ45 connectors and associated logic (PHYs) on the FPGA board so that I can process multiple ethernet streams on the FPGA. Can anyone suggest any such board? or any add-on module which can be hooked up on some particuar FPGA board providing multiple ethernet connections ! Best Regards FarhanArticle: 117299
On Mar 25, 7:54 am, "Edmond Cot=E9" <edmond.c...@gmail.com> wrote:
> Hi,
>
> I would like to load a on-chip ROM in a Altera Stratix device with the
> data produced by the linker script shown below. Since the text segment
> is not located at address 0x00000000, ModelSim, or altera_mf.v rather,
> produces the following error:
>
> # ERROR: rom.hex, line 1, Unknown record type.
> # ERROR: rom.hex, line 1, Invalid checksum.
>
> Any suggestions? I'm basically looking for a way to relocate the base
> address to 0 without actually affecting the data produced by the
> linker, as I need to keep everything statically linked.
>
> Thanks,
>
> Edmond
>
> --- rom.ld (linker script) ---
>
> MEMORY
> {
> rom : ORIGIN =3D 0x08000000, LENGTH =3D 4k
>
> }
>
> SECTIONS
> {
> .text :
> {
> . =3D ALIGN(4);
> *(.text)
> _text_end =3D . ;
> } > rom
>
> }
>
> --- rom.hex ---
>
> :020000040800F2
> :100000003C040A0024080005AC8800002408000A0B
> :100010000E000041000000000000000D0000000084
> :1000200000000000000000000000000000000000D0
> :1000300000000000000000000000000000000000C0
> :1000400000000000000000000000000000000000B0
> :1000500000000000000000000000000000000000A0
> :100060000000000000000000000000000000000090
> :100070000000000000000000000000000000000080
> :100080000000000000000000000000000000000070
> :100090000000000000000000000000000000000060
> :1000A0000000000000000000000000000000000050
> :1000B0000000000000000000000000000000000040
> :1000C0000000000000000000000000000000000030
> :1000D0000000000000000000000000000000000020
> :1000E0000000000000000000000000000000000010
> :1000F0000000000000000000000000000000000000
> :100100000000000D1500FFFF2108000103E00008BA
> :1001100000000000000000000000000000000000DF
> :1001200000000000000000000000000000000000CF
> :1001300000000000000000000000000000000000BF
> :1001400000000000000000000000000000000000AF
> :10015000000000000000000000000000000000009F
> :10016000000000000000000000000000000000008F
> :10017000000000000000000000000000000000007F
> :10018000000000000000000000000000000000006F
> :10019000000000000000000000000000000000005F
> :1001A000000000000000000000000000000000004F
> :1001B000000000000000000000000000000000003F
> :1001C000000000000000000000000000000000002F
> :1001D000000000000000000000000000000000001F
> :1001E000000000000000000000000000000000000F
> :1001F00000000000000000000000000000000000FF
> :0400000508000000EF
> :00000001FF
Hi Edmund,
Our simulation team says that you have hit a missing feature in the
altera_mf.v simulation model (extended linear address record), and
they have opened a software issue to track adding this feature to a
future release of Quartus. In the interim, you should be able to
remove the first line of the hex file and the ROM contents should be
relocated to base address 0, allowing correct simulation.
Vaughn
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