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
-- (all previous threads clipped) I've been floorplanning in VHDL for years. The first serious design I did was in 1995, about 38K gates in a 40K gate ORCA device. I had to implement a 64 bit pipelined bubble sort running at 50 MHz. The only way to get it to route was to design 2 interlocking hard macros and tile the array with them. Even back in 95, the Exemplar tools would attach edif properties to black box cells instantiated in the code. I just wrote a VHDL function to turn the (i,j) address of the hard macro into a character string, and then attached a LOC attribute to the cell instantiation inside a double loop. The resulting EDIF had each hard macro instantiation include an EDIF property that gave the place & route tool the precise location for the hard macro. The same principal applies to primitive cells from the schematic library. Austin Franklin is perfectly correct when he says that you have to instantiate EVERYTHING that needs floorplanning. I will go even further and proclaim that this is a superior method of design, as long as the primitive cells are properly wrapped up in a higher level component so that you don't actually see them in your user code. I have since written VHDL functions that take some vector or block parameters and use them to compute vectors of location strings that get attached to a string of flip-flops in a register. Often, placing a few critical registers is enough to get the rest of the design to fall into place very nicely. It's very easy actually, see the floorplanning example on my web page at http://www.lucent.ca/fpga/register.htm#Floorplanning But as before, floorplanning is something you resort to only when you really need it. I don't consider IO assignment to be floorplanning, and this is often all that you need to do to get a reasonable result. John McCluskey Lucent Technologies P.S. To Stuart Clubb.... I've got a working gray code counter for ORCA now. It's pretty fast. A 12 bit counter runs at 150 MHz in a 3T30-6, and adding a synchronous preload function only drops it to down to 101 MHz.Article: 11101
On 18 Jul 1998 02:08:45 GMT, "Austin Franklin" <darkroo5m@ix.netcom.com> wrote: >I noticed the amount of personal, corporate and head hunter advertising in >this news group has increased dramatically. > >Personally, I find all this advertising in VERY poor taste. I do not >believe it is in this groups charter to make this an advertising group, it >IS a discussion group. > >Though people talking about new products, or web sites is great, >advertising you offer some consulting service, or are a head hunter looking >for names, I believe, is inappropriate. > >Any body else tired of all this advertising? Yes, but there's not much you can do about this. Perhaps the best thing you can do is to reply to their postings; these people rely on goodwill and an unfavourable reply will soon shut them up. I've tried this myself recently. Head hunter postings can also be counter-productive. There was a posting last month that gave me just enough information to be able to do a search for the client, who turned out to be a couple of miles down the road from me. So I contacted them directly, cutting out the agency... :) Evan (ems@nospam.riverside-machines.com)Article: 11102
On Fri, 17 Jul 1998 16:32:51 -0400, Ray Andraka <no_spam_randraka@ids.net> wrote: > (HDL/schematic pros/cons snipped) Agreed, in general, but I think you're seriously underselling the simulation advantages of an HDL: > 1) the ability to simulate the design behaviorally while the design is still >just a concept The real advantage is that you can write an entire testbench in your HDL. Not just your device, but the system around it. You can then use the same testbench for simulation at any stage of the implementation process, assuming that you can sort out any name changes. You can also write far more complex scenarios in your HDL than you could in the scripting 'language' provided with your gate-level simulator. If simulation is important to you, then my opinion would be that you have no option other than to use an HDL. Ok, this may (will) give you major floorplanning problems, and it may be (very) time-consuming to produce a fast design. But at the end of the day you can deliver a re-usable design, in an industry-standard HDL, with a robust simulation package. The alternative is to deliver a large number of schematics, and a questionable simulation, probably produced with a mickey-mouse package which will be obsolete by the time you have to modify the sources. Evan (ems@nospam.riverside-machines.com)Article: 11103
Has anyone done any CRC-16 implementations in an FPGA? I am looking for the CRC-CCITT implementaton in particular. Any help or pointers to information at all would be appretiated? Thanks in Advance, Richard -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 11104
Austin, About the tristates... You are correct that they are free logic in the XILINX architecture parts, but be aware that when porting to an ASIC or non tristate part, that excesive use of tristates as muxes will blow the design size up when the tristates are converted back to muxes. Also the work invloved and the design route changes need to be considered. Richard Austin Franklin wrote: > Everything Ray says is absolutely correct about this subject (that'll be $5 > Ray ;-). > > HDLs do not give a consistent platform for floorplanning unless you > instantiate EVERYTHING you are going to floorplan. Even then, if you > fart...er change a line of code, you can change the entire structure of the > output from the HDL. Even different revisions of the HDL tools will change > the names! > > I also agree with doing regular structures (registers, busses, counters, > muxes...) in schematic, so you CAN floorplan then EASILY (and I believe it > is far easier to read than HDL). Overall it takes FAR LESS TIME than doing > these things in HDLs. I could care less what you want to do your random > logic/state machines in, schemtaic or HDLs, but I STRONGLY advise doing > regular structures in schematic. It is not archiac, it is using the > correct tool CORRECTLY for the job. > > More than half my contracts are from supposed HDL experts who, when > designing for an FPGA, complain that it only runs at 10MHz, and they can't > figure out why. Funny how after I either instantiate everything to allow > for 'pseudo' consistent naming conventions, and floorplan it, or change > their wizardry HDL (cough cough) into schematics, and floorplan it, the > design all of a sudden routes in minutes (as opposed to hours) and runs at > over 2x-4x (I've seen as high as 10x) speed as the HDLs. > > Enough said...yes, floorplanning a 4028 (any Xilinx FPGA for that matter > that the design uses regular structures) is very prudent. Another gotcha > (well, I guess not enough said) that most HDL designers fail on is to NOT > use the internal tri-state busses as muxes for register I/O....YOU WANT TO > USE THEM IF YOU CAN. They are free logic (not counted in the parts gate > count) AND they are fast, and can have a large number of > sources/destinations on the 'bus'. > > Now, enough said...for now ;-) > > Austin Franklin > darkroom@ix.netcom.com > > Ray Andraka <no_spam_randraka@ids.net> wrote in article > <35AFB4F3.FD40122C@ids.net>... > > > > > > Jan Gray wrote:: > > > > > Is there an HDL to netlist synthesis tool that either -- > > > 1) supports placement constraint attributes on register declarations > and/or > > > on subexpressions? (not just pin-locking) or > > > 2) uses systematic, repeatable names for generated elements of the > > > synthesized netlist, enabling external placement constraints? (It is > not > > > acceptable if a small change to the HDL source renames all the > synthesized > > > stuff, invalidating the external floorplan or guide files.) > > > > > > > NOT YET. My local Exemplar rep claims the new spectrum tool will be able > to > > carry placement info. I haven't played with it yet, so I don't know. > This is > > the reason I still use and advocate schematic entry (I've been accused of > > working in the dark ages and worse because of this...working in the dark > maybe, > > dark ages: I don't think so). The fact is, if you do hierarchical > schematics > > right, you get just as much reuse (even to different architectures) and I > think > > more readability than the HDLs proport to have. My schematic library > consists > > of a lot of 1 and 2 bit objects (including carry chain stuff) that I can > quickly > > stack to make arbitrary width doo-dads using the array command. > > > > After you cut through all the marketing BS, the only real advantages (and > not > > insignificant by any means) that HDLs have over schematics are > > 1) the ability to simulate the design behaviorally while the design is > still > > just a concept, and > > 2) the ability to browse an archived design without having a copy of > the > > schematic editor used to create the design. > > everything else is just as easy to accomplish with a good schematic entry > > habits. Current shortcomings of HDLs are > > 1) readability suffers (this is the old a picture is worth a thousand > > words...of course the schematics need to be done in a way that makes > visual > > sense-a 60 page flat schematic doesn't cut it). The software world is > > recognizing this and going toward all kinds of GUI's and visual this and > that. > > Meanwhile the hardware guys are moving away from pictoral representation > in > > favor of text. Go figure. > > 2) the HDLs currently provide no easy means to control placement in the > > design, and > > 3) a user has to understand the all the little quirks of the particular > > version of the synthesis tool he is using to gain any sense of control > over the > > design implementation. > > > > I'd really like to have the two advantages I cited, but until the > shortcomings > > are addressed, I will prefer schematics because I get better results in > less > > time. That means more money to me (much of my work is on a fixed price > basis) > > > > > In lieu of these features, one approach would be to write and verify > the > > > entire design in an HDL, then reimplement the significant datapath > modules > > > using explicit instantiation and placement via schematics or netlist > > > generator. You get quick design, simulation, synthesis (target other > > > devices), possibility of design reuse, *and* optimal use of FPGA > resources > > > so you can use a smaller slower cheaper device. > > > > > > I have been searching for this happy medium myself. As I write on the > > > pleasures of designing processors and systems-on-chip in FPGAs, I want > to > > > express the designs > > > 1) in source code, that > > > 2) can be simulated, and which > > > 3) enables compilation to non-Xilinx devices, and > > > 4) enables reuse of preexisting designs from other sources, and > > > 5) uses device features as efficiently as does my netlist generator, > e.g. > > > which permits floorplanning. > > > > > > I'd like to use Verilog because of 1-4, anticipating a future Xilinx > Student > > > Edition with Verilog -- but I'm not willing to sacrifice my > > > nice, half as large, twice as fast, quick-place-and-route datapaths! > Any > > > ideas? Otherwise its going to be either a) 100% netlist generator > > > (sacrificing 3-4) or b) Verilog + datapaths reimiplemented via netlist > > > generator. > > > > Jan, the available cores are increasing, so it is becoming a little > easier to > > get the performance out of an HDL. Often, a core library vendor will > include > > behavioral models (I think it is a requirement to be a xilinx alliance > partner) > > for VHDL and Verilog, a schematic symbol and a placed netlist. Right now > the > > available library doesn't include enough functions to make it all work, > but > > maybe as the libraries grow? > > > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka > > > > > > -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 11105
Austin, I am now very curious about floorplanning and creating HDL "BLOCKS" for instantiating so that I can use the floorplanner. First off I assume that I create a type of MACRO with the VHDL ? How exactl;y would this be done ? I see the merrits of what you and Ray A. are saying, and have heard similar sentiments from good designers like my friend Philip F. , I also am always generating top level block flow diagrams which are essentially just my top level VHDL files. It would be great if this was automatically generated. I work in an environment where: 1) Detailed Simulations are invariablly required. 2) Detailed back annotated timing is highly desired 3) Migration to Gate Arrays are inevitable. (HDLs are a big plus here) 4) Migration to ever changing FPGAs are inevitable (XILINX to ORCA to Altera to ACTEl etc.) The last two issues involve code reuse. This is another problem I see in using device specific Macros. If I have a project which is heavily device dependent (macros etc), It really ties me to a particular device. For real preformance, it seems to me that this is where much of vendors are heading, creatuing device specific "core" or macros, which are optimized for the specific technology of the parts being used. The problem that crops up is that at any one point in time a specific vendor may have a part that better fits the design. HDLs should theoretically solve this problem, where you simply re-synthesize to the new parts architecture. The problem being that using device specific macros requires that a you find, or generate new macros in the new technology. This not a real problem if you only do small macros for ram etc., but when the majority of your design is geared towards these macros then your in for alot of work, which in most cases is not practical for any reasonable schedule. It also seems to me that the heavy macro use is roughly equivalent to tying together schematic symbols using a VHDL netlist. The only reason to use the HDL over the schematics is then to take advantage of the superior simulation properties. Even with all the advantages you seem to point to, it still seems to me that the future points to HDLs. For most general purpose designs which are pushing the envelope of performance out of a part, the HDLs seem to be the way to go. That being said, I also see a huge disconnect between synthesis code and actual hardware implementation that does not seem to be easily overcome. Knowing how each synthesis tool and place and route tools implement specific language constructs is still --for the most part-- a mystery to the average engineer. Breaching that disconnect ( a disconnect that is easily overcome with schematic tools) is hopefully where the developers of HDL tool standards will spend a good chunk of time. I have adopted this strategy so far for programmable logic developement: 1) Use HDL. 2) Do functional simulations with HDL simulators. 3) Keep HDL as general as possible and avoid device specific macros/cores unless the design requirements push you towards them. 4) Stay with one vendor for most designs unless there is a HUGE reason to switch. This rule keeps the device specfic macro problem to a minimum, and allows for more code reuse and keeps your overall knowledge base focused, allowing more time to understand the specific architecture of the vendor you specialize in. 5) Use as much post route information as possible and constrain designs based on that information in order to get the desired placement and routing. This includes examining the placement are doing designs. I really would like more information on the way some use HDL and Floorplanning tools. I always assumed that the floorplaning would almost have to be done as a last process. A process that would not allow easily code changes in the HDL without redoing the floorplanning each time. I would really like to see the way HDL and floorplanning is incorporated in a managable way. Austin Franklin wrote: > Everything Ray says is absolutely correct about this subject (that'll be $5 > Ray ;-). > > HDLs do not give a consistent platform for floorplanning unless you > instantiate EVERYTHING you are going to floorplan. Even then, if you > fart...er change a line of code, you can change the entire structure of the > output from the HDL. Even different revisions of the HDL tools will change > the names! > > I also agree with doing regular structures (registers, busses, counters, > muxes...) in schematic, so you CAN floorplan then EASILY (and I believe it > is far easier to read than HDL). Overall it takes FAR LESS TIME than doing > these things in HDLs. I could care less what you want to do your random > logic/state machines in, schemtaic or HDLs, but I STRONGLY advise doing > regular structures in schematic. It is not archiac, it is using the > correct tool CORRECTLY for the job. > > More than half my contracts are from supposed HDL experts who, when > designing for an FPGA, complain that it only runs at 10MHz, and they can't > figure out why. Funny how after I either instantiate everything to allow > for 'pseudo' consistent naming conventions, and floorplan it, or change > their wizardry HDL (cough cough) into schematics, and floorplan it, the > design all of a sudden routes in minutes (as opposed to hours) and runs at > over 2x-4x (I've seen as high as 10x) speed as the HDLs. > > Enough said...yes, floorplanning a 4028 (any Xilinx FPGA for that matter > that the design uses regular structures) is very prudent. Another gotcha > (well, I guess not enough said) that most HDL designers fail on is to NOT > use the internal tri-state busses as muxes for register I/O....YOU WANT TO > USE THEM IF YOU CAN. They are free logic (not counted in the parts gate > count) AND they are fast, and can have a large number of > sources/destinations on the 'bus'. > > Now, enough said...for now ;-) > > Austin Franklin > darkroom@ix.netcom.com > > Ray Andraka <no_spam_randraka@ids.net> wrote in article > <35AFB4F3.FD40122C@ids.net>... > > > > > > Jan Gray wrote:: > > > > > Is there an HDL to netlist synthesis tool that either -- > > > 1) supports placement constraint attributes on register declarations > and/or > > > on subexpressions? (not just pin-locking) or > > > 2) uses systematic, repeatable names for generated elements of the > > > synthesized netlist, enabling external placement constraints? (It is > not > > > acceptable if a small change to the HDL source renames all the > synthesized > > > stuff, invalidating the external floorplan or guide files.) > > > > > > > NOT YET. My local Exemplar rep claims the new spectrum tool will be able > to > > carry placement info. I haven't played with it yet, so I don't know. > This is > > the reason I still use and advocate schematic entry (I've been accused of > > working in the dark ages and worse because of this...working in the dark > maybe, > > dark ages: I don't think so). The fact is, if you do hierarchical > schematics > > right, you get just as much reuse (even to different architectures) and I > think > > more readability than the HDLs proport to have. My schematic library > consists > > of a lot of 1 and 2 bit objects (including carry chain stuff) that I can > quickly > > stack to make arbitrary width doo-dads using the array command. > > > > After you cut through all the marketing BS, the only real advantages (and > not > > insignificant by any means) that HDLs have over schematics are > > 1) the ability to simulate the design behaviorally while the design is > still > > just a concept, and > > 2) the ability to browse an archived design without having a copy of > the > > schematic editor used to create the design. > > everything else is just as easy to accomplish with a good schematic entry > > habits. Current shortcomings of HDLs are > > 1) readability suffers (this is the old a picture is worth a thousand > > words...of course the schematics need to be done in a way that makes > visual > > sense-a 60 page flat schematic doesn't cut it). The software world is > > recognizing this and going toward all kinds of GUI's and visual this and > that. > > Meanwhile the hardware guys are moving away from pictoral representation > in > > favor of text. Go figure. > > 2) the HDLs currently provide no easy means to control placement in the > > design, and > > 3) a user has to understand the all the little quirks of the particular > > version of the synthesis tool he is using to gain any sense of control > over the > > design implementation. > > > > I'd really like to have the two advantages I cited, but until the > shortcomings > > are addressed, I will prefer schematics because I get better results in > less > > time. That means more money to me (much of my work is on a fixed price > basis) > > > > > In lieu of these features, one approach would be to write and verify > the > > > entire design in an HDL, then reimplement the significant datapath > modules > > > using explicit instantiation and placement via schematics or netlist > > > generator. You get quick design, simulation, synthesis (target other > > > devices), possibility of design reuse, *and* optimal use of FPGA > resources > > > so you can use a smaller slower cheaper device. > > > > > > I have been searching for this happy medium myself. As I write on the > > > pleasures of designing processors and systems-on-chip in FPGAs, I want > to > > > express the designs > > > 1) in source code, that > > > 2) can be simulated, and which > > > 3) enables compilation to non-Xilinx devices, and > > > 4) enables reuse of preexisting designs from other sources, and > > > 5) uses device features as efficiently as does my netlist generator, > e.g. > > > which permits floorplanning. > > > > > > I'd like to use Verilog because of 1-4, anticipating a future Xilinx > Student > > > Edition with Verilog -- but I'm not willing to sacrifice my > > > nice, half as large, twice as fast, quick-place-and-route datapaths! > Any > > > ideas? Otherwise its going to be either a) 100% netlist generator > > > (sacrificing 3-4) or b) Verilog + datapaths reimiplemented via netlist > > > generator. > > > > Jan, the available cores are increasing, so it is becoming a little > easier to > > get the performance out of an HDL. Often, a core library vendor will > include > > behavioral models (I think it is a requirement to be a xilinx alliance > partner) > > for VHDL and Verilog, a schematic symbol and a placed netlist. Right now > the > > available library doesn't include enough functions to make it all work, > but > > maybe as the libraries grow? > > > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka > > > > > > -- __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ Richard Schwarz, President EDA & Engineering Tools Associated Professional Systems (APS) http://www.associatedpro.com 3003 Latrobe Court richard@associatedpro.com Abingdon, Maryland 21009 Phone: 410.569.5897 Fax:410.661.2760 __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/Article: 11106
If everyone who has things to advertise does so, the technical content will be overwhelmed, perhaps to the loss of our community. What do you suppose is an ethical course of action...? At any rate, the folks that continue to post pure advertising could take some initiative to minimize the dillutive effect. For example, 1. pay to advertise on one of the fine FPGA web sites instead. 2. find/hire someone to digest and post a recurring ads message. You'll get more consistent reach. This works beautifully on comp.compilers (moderated). 3. try to achieve a common set of subject tag lines, e.g. "ad: job: " and "ad: consulting: " etc. But reread the first sentence of my posting. 4. perhaps the most effective advertising for consultants and design services is to instead emulate the several experts who contribute so profoundly to the technical dialog in this newsgroup. ems wrote in message <35b1fcd3.16762706@news.dial.pipex.com>... >Yes, but there's not much you can do about this. Perhaps the best >thing you can do is to reply to their postings; these people rely on >goodwill and an unfavourable reply will soon shut them up. I've tried >this myself recently. I stopped doing this when a single polite private reply was returned with vitriol and then with a threat of legal action for my "persistent attacks" on the head-hunter's business. Apparently others complained directly to his ISP who was going to pull the plug, and he blamed his situation on me. Jan GrayArticle: 11107
Brad Smallridge wrote: I need a hardware implementation to find a unique number for a bit pattern that is shifted. Below is a four bit example although our requirements are for something larger: Input > Transform 0000 > 0000 0001 > 1000 0010 > 1000 0011 > 1100 0100 > 1000 0101 > 1010 0110 > 1100 0111 > 1110 1000 > 1000 1001 > 1100 corrected as pointed out by Rickman. 1010 > 1010 1011 > 1011 1100 > 1100 1101 > 1101 1110 > 1110 1111 > 1111 Obvisously, all I did here was to shift the input pattern until it maximised. The output of the transform is shift invarient, ie. 0001 maps to the same number as 0100. We are considering doing this,shifting and testing for max, however, it takes a lot of clock cycles. I would rather have a logic gate solution. A look-up-table approach is too costly for the input width we have in mind. The transform can also compress data, for example, the 4 bit example above has 16 input vectors and maps to only 10 outputs. Thanks in Advance, Brad Smallridge www.sightech.com Rickman wrote: This is a problem that has been designed many times before. This is the same as the normalization step in a floating point add/sub. You count the leading zeros in the mantissa and shift left the result. This consists of two circuits; one to count the leading zeros, and a barrel shifter to shift the data by the count amount. The barrel shifter is trivial to design although it will take a lot of gates to implement as the word size gets large. I don't remember the best way to design the leading zero counter, but I can suggest one that will work. The brute force method is to add the zeros one bit at a time masking all bits after a one is detected... (be sure to view with a monospaced font) MSB LSB | | | | | | | +--O +--O +--O +--O | |---|-|--R->---|-|--R->---|-|--R--> o o o ---|-|--R->---| | | | | | | | | | | | | INV NOR NOR NOR NOR NOR | __|__ __|__ __|__ __|__ __|__ SHIFT | | | | | | | | | | | COUNT +-| + |===>| + |===>| + |===> ==| + |===>| + |===> |_____| |_____| |_____| |_____| |_____| OUTPUT The count that comes out will be 5 bits wide. This will have a slow ripple time. But that can be sped up by performing parts of the computation in parallel like a carry look ahead adder. Brad Smallridge wrote: Hmm. Good start but consider these two bit fields: 01100011010 01101011000 which, would shift only once according to your algorithm, but are non-the-less shift invarient equivalent. Brad Smallridge www.sightech.com Rickman wrote: I may not understand your question. I thought you were asking for an IMPLEMENTAION of your agorithm to shift a bit pattern so that the most significant "one" bit ended up in the MSb posistion. I don't understand what you are saying about the two patterns above being "shift invarient equivalent". Can you explain that a little more? What result would you like to produce from the above patterns? Brad Smallridge answers: OK. First I made a mistake. As Achim Gratz pointed out. The bit patterns should be: 01100011010 11010011000 so the top pattern should shift 6 times to the left. They would then both be equivalent at 11010011000. And likewise the pattern: 01001100011 should shift left 10 times left and also be equivalent. Should I be using the word rotate instead of shift? So, you see, it's not merely looking for a leading 1. And it seems to be more than looking for the longest run of 1s also. Consider these strings: 01010100101 01001010101 And also I'm not necesarilly looking for an output number that saves the bit pattern of the input. As I stated above, there may be some compression involved, since many patterns will transform to the same output signal. Thanks, Rick Collins: I think I have it now. You want a mapping of the set of all inputs for a given bit size to the set of "shift invariant equivalence" groups. This is not so easy. To do this I suspect that you would need to define an ordering sequence for your "shift invariant equivalent" groups. Then you can map your input to the corresponding group by rotating it until it matches the first member of the group. For example, you could define your ordering to be in sequence of magnatude of the binary value. This would provide you with an algorithm of shifting the bit pattern so that the longest string of zeros is at the left, if there is more than one string of zeros of equal maximal length, then you shift to left justify the longest string of zeros with the shortest string of ones on its right, and so on... This will ultimately map all members of a "shift invariant equivalence" group to a single bit pattern, which is what I think you are asking. Now the trick is to identify an ordering sequence that will allow you specify a simple algorithm which can be implemented in combinatoral logic without a multi clock state machine. Some trick, huh? I don't believe you will find a solution to this problem that will be very easy to implement. I think all solutions will either take a great deal of logic, or will require a lot of clock cycles to produce a result. In the case of the latter, you can pipeline it to produce a result on every clock cycle even though it may take many clocks for a given result to work its way through the pipe (both lots of logic and lots of clocks). [The table] is not correct. 1001 maps to 1001 while 1100, 0110 and 0011 all map to 1100. In fact all four bit patterns should map to the same "shift invarient equivalent" group. When you say this transform can compress data, I don't think you will get much compression. As I see it you will be compressing data from 2**n using n bits to (2**n)/n using n - log2(n) bits for a savings of (log2(n)/n) * 100%. For 32 bit words this is only 5/32 or about 15%. Is that worth the trouble? Does it sound like I understand your problem now? Brad Smallridge writes: Yes. You got it. It is more difficult then it seems. That's why I'm on the net. And I believe a prioity encode, as Brian Drummond suggests, is just another first one detector. You are right about the table and I have corrected it in this current post with credit to you. I am not sure about your compression calculation. I am not so good at decyphering log n type mathematics. It seems to me that the compression should be enormous. When I was working on a five bit table, and doing the shift to maximise routine, the LSB was 0, all except for the input vector 11111. So this LSB has little information, and could be dropped, if you transform 11111 to some unused 4 bit output, say 0001. So there is a 5 bit to 4 bit compression. Does that hold with your formula? I also had a thought the other night that I should take the ones bit count as a start. Trouble with the 4 bit patterns appears with the vectors 1100 and 1010. So I thought I should AND all adjacent bits and count these outputs as well. That solves the 4 bit pattern and also 5 bits ... I think. But eventually I will run into bit patterns like this: 0110110000000 0110000110000 Where the ones count and the pairs of ones count is exactly the same. So should I count pairs of zeroes too? Doesn't seem to be getting me anywhere.Article: 11108
I too, am concerned. When the traffic on comp.lang.verilog escalates to the noise of alt.tv.x-files - I know I'll be outta here. I've always thought it fair that independents or small firms may include a 4-5 line email signature trailer (with WWW site, phone #, etc.), but for us to see it, they simply have to contribute to our group with some good insightful replies. Give and Take. tom coonan tcoonan@mindspring.com Scientific Atlanta >I noticed the amount of personal, corporate and head hunter advertising in >this news group has increased dramatically. > >Personally, I find all this advertising in VERY poor taste. I do not >believe it is in this groups charter to make this an advertising group, it >IS a discussion group. > >Though people talking about new products, or web sites is great, >advertising you offer some consulting service, or are a head hunter looking >for names, I believe, is inappropriate. > >Any body else tired of all this advertising? > >Austin Franklin >darkroom@ix.netcom.com >Article: 11109
I'd like to toss my 2 cents in. If an Altera FAE want to respond to my attacks on AHDL, or a Xilinx engineer wants to correct a mis-representation of their product (there's one that does, and his posts are useful), that's a good thing. Of if OrCAD would read the groups, and find out how many people are complaining about bugs and non-support. In otherwords, if a manufacturer or sales person is responding, rather than generating, that's good. And as far as head hunters go: IMHO, I would never seek representation for an individual or firm that was too dense to figure out that their posts don't belong here. Last time I checked, there was an 'xxx.jobs.xxx' group for just about every corner of the world. Gary. Jan Gray wrote: > > If everyone who has things to advertise does so, the technical content will > be overwhelmed, perhaps to the loss of our community. What do you suppose > is an ethical course of action...? > > At any rate, the folks that continue to post pure advertising could take > some initiative to minimize the dillutive effect. For example, > > 1. pay to advertise on one of the fine FPGA web sites instead. > > 2. find/hire someone to digest and post a recurring ads message. You'll get > more consistent reach. This works beautifully on comp.compilers > (moderated). > > 3. try to achieve a common set of subject tag lines, e.g. "ad: job: " and > "ad: consulting: " etc. But reread the first sentence of my posting. > > 4. perhaps the most effective advertising for consultants and design > services is to instead emulate the several experts who contribute so > profoundly to the technical dialog in this newsgroup. > > ems wrote in message <35b1fcd3.16762706@news.dial.pipex.com>... > >Yes, but there's not much you can do about this. Perhaps the best > >thing you can do is to reply to their postings; these people rely on > >goodwill and an unfavourable reply will soon shut them up. I've tried > >this myself recently. > > I stopped doing this when a single polite private reply was returned with > vitriol and then with a threat of legal action for my "persistent attacks" > on the head-hunter's business. Apparently others complained directly to his > ISP who was going to pull the plug, and he blamed his situation on me. > > Jan GrayArticle: 11110
In article <6ots61$6rp@masters0.InterNex.Net>,
"Brad Smallridge" <manbike@smallridge.xo.com> wrote:
> It seems to me that the compression should be enormous.
> When I was working on a five bit table, and doing the
> shift to maximise routine, the LSB was 0, all except
> for the input vector 11111. So this LSB has little information,
> and could be dropped, if you transform 11111 to some unused
> 4 bit output, say 0001. So there is a 5 bit to 4 bit compression.
> Does that hold with your formula?
The compression factor Rickman gives is correct; what it tells you is
that the 2^n bit strings of length n will map to roughly 2^n/n possible
patterns (equivalence classes). The number of possible patterns actually
has a closed form solution and for n=1..32 is :
[ 2, 3, 4, 6, 8, 14, 20, 36, 60, 108, 188, 352, 632, 1182, 2192, 4116, 7712,
14602, 27596, 52488, 99880, 190746, 364724, 699252, 1342184, 2581428,
4971068, 9587580, 18512792, 35792568, 69273668, 134219796 ]
so for n=1 you have two patterns ("0" and "1"), for n=2 you have 3 ("00",
"01","11"), for n=3 you have 4 ("000","001","011","111"); and so on. You
can divide by 2^n to see the ratio. So no matter how you encode the outcome,
there are about 2^n/n possible values.
> I also had a thought the other night that I should take the ones
> bit count as a start. Trouble with the 4 bit patterns appears
> with the vectors 1100 and 1010. So I thought I should AND
> all adjacent bits and count these outputs as well. That solves
> the 4 bit pattern and also 5 bits ... I think. But eventually I will
> run into bit patterns like this:
> 0110110000000
> 0110000110000
> Where the ones count and the pairs of ones count is exactly the
> same. So should I count pairs of zeroes too? Doesn't seem to be
> getting me anywhere.
This is actually along the lines of what you have to do : you need
to find "shift-invariant functions" that give the same output for
all inputs that are shifts of each other, *and* you need to find
enough of these functions to completely distinguish between all
posssible patterns. One such function is the number of 1's in the string,
this function is enough for n=1,2,3; for n=4 you have two patterns that
have the same number of 1's : ("0011" and "0101") so you need a function
to distinguish between these two; the function :
c1*c2 + c2*c3 + c3*c4 + c4*c1
distinguishes between the two; it's 1 for "0011" and 0 for "0101". You
can also see that it is invariant under rotation. Note that the number
of 1's corresponds to the function : c1+c2+c3+c4. If you're interested
in bit strings of length 4 then two functions are enough and you're done.
Otherwise you keep adding functions as you need them. For example :
c1*c2 + c2*c3 + c3*c4 + c4*c5 + c5*c1 or
c1*c3 + c2*c4 + c3*c5 + c4*c1 + c5*c2 or
c1*c2*c3 + c2*c3*c4 + ... (keep rotating the terms)
can be used for larger n. There's probably a systematic way of adding
these functions or even some kind of tranform (along the lines of a
Fourier Transform which is realy a shift invariant tranform if you
just look at the amplitude of the spectrum); this seems like a good
question to post to one of the math groups.
Jacob Hirbawi.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Article: 11111Brad Smallridge wrote: > Brad Smallridge writes: > Yes. You got it. > It is more difficult then it seems. That's why I'm on the net. > And I believe a prioity encode, as Brian Drummond suggests, > is just another first one detector. > You are right about the table and I have corrected it > in this current post with credit to you. > I am not sure about your compression calculation. I am > not so good at decyphering log n type mathematics. > It seems to me that the compression should be enormous. > When I was working on a five bit table, and doing the > shift to maximise routine, the LSB was 0, all except > for the input vector 11111. So this LSB has little information, > and could be dropped, if you transform 11111 to some unused > 4 bit output, say 0001. So there is a 5 bit to 4 bit compression. > Does that hold with your formula? > I also had a thought the other night that I should take the ones > bit count as a start. Trouble with the 4 bit patterns appears > with the vectors 1100 and 1010. So I thought I should AND > all adjacent bits and count these outputs as well. That solves > the 4 bit pattern and also 5 bits ... I think. But eventually I will > run into bit patterns like this: > 0110110000000 > 0110000110000 > Where the ones count and the pairs of ones count is exactly the > same. So should I count pairs of zeroes too? Doesn't seem to be > getting me anywhere. My guesstimate of compression comes from the number of "shift invariant equivalence" (SIE) groups vs. the number of possible bit patterns for a given number of bits. Obviously there are 2**n number of bit patterns. Any given SIE group can be created by picking a starting pattern and shifting through all the possible patterns until you have shifted by n where the original pattern is guaranteed to repeat. Therefor, the largest number of members of any given SIE group will be n, while many will be less. The number of SIE groups will then be no less than 2**n/n. To find the amount of compression this will produce, consider the number of bits to represent the compressed data; n vs. log2((2**n)/n) or log2(2**n) - log2(n) or n - log2(n). This gives a relative savings of log2(n)/n. If n is 32, then log2(n) is 5 and 5/32 is about 15%. And remember that this is an upper limit which will never be reached! 15% compression is not very big, and it is only useful if you don't care about distinguishing between SIE group members. What would be the application where this would apply? -- Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 11112
ems wrote: > > On 18 Jul 1998 02:08:45 GMT, "Austin Franklin" > <darkroo5m@ix.netcom.com> wrote: > > >I noticed the amount of personal, corporate and head hunter advertising in > >this news group has increased dramatically. ... snip ... > >Any body else tired of all this advertising? > > Yes, but there's not much you can do about this. Perhaps the best > thing you can do is to reply to their postings; these people rely on > goodwill and an unfavourable reply will soon shut them up. I've tried > this myself recently. I have tried this as well. There is one company (I won't mention their name, but their initials are Kalman Saffran Associates, Inc. ;-) that is posting spam to a couple of mailing lists that I am on. I send them a reply for every posting that I get. When they contacted me by phone I told the salesman what I thought of their marketing method. He insisted that there was nothing improper with using the same marketing techniques as chain letters, scam artists and smut peddlers. I don't think I will be getting a follow up call. > Head hunter postings can also be counter-productive. There was a > posting last month that gave me just enough information to be able to > do a search for the client, who turned out to be a couple of miles > down the road from me. So I contacted them directly, cutting out the > agency... :) > > Evan (ems@nospam.riverside-machines.com) -- Rick Collins rickman@XYwriteme.com remove the XY to email me.Article: 11113
Hello Everybody
I don't know how to implement my previous ASIC-design counter with 2 edge
triggers -- up and down (up => increment the counter by 1; down [i.e. dn] =>
decrement the counter by 1) I used logic gates to implement this function but
it seems difficult to describe this with VHDL. I know that another writing of
up-down counter is to use a pin to control up/down and another is just a
clock for incrementing / decrementing the counter.
My 4-bit counter, however, uses four 4-bit counter to connect together by:
Carry => UP
('Carry' of lower-bit counter connected to 'UP' of another counter)
Borrow => DN
Below is a correct but unsynthesizable (by ViewLogic) code of 16-bit counter.
Could anyone tell me any idea?
Thanks a lot in advance.
-- Leslie Yip, ASM; July, 17
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
Entity COUNTER is
port( NRST: in std_logic;
LOAD: in std_logic;
ENABLE: in std_logic;
UP,DN: in std_logic;
BUSIN: in std_logic_vector(15 downto 0);
CARRY,BORROW: out std_logic;
CNTOUT: out std_logic_vector(15 downto 0)
);
end COUNTER;
architecture COUNTER_ARCH of COUNTER is
signal CNT: std_logic_vector(15 downto 0);
begin
process(NRST,LOAD,UP,DN)
begin
if NRST = '0' then
CNT <= (others=>'0');
CARRY <= '0';
BORROW <= '0';
elsif LOAD='1' then
CNT <= BUSIN;
elsif UP='1' and UP'event and ENABLE = '1' then
if CNT = "1111111111111111" then
CARRY <= UP;
else
CARRY <= '0';
end if;
CNT <= CNT + 1;
elsif DN='1' and DN'event and ENABLE = '1' then
if CNT = "0000000000000000" then
BORROW <= DN;
else
BORROW <= '0';
end if;
CNT <= CNT - 1;
end if;
end process;
CNTOUT <= CNT;
end COUNTER_ARCH;
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Article: 11114Hi, I have xilinx alliance (M1.4 with viewlogic 7.4) on NT 4.0 SP3. No problems with Dynatext! But my Foundation System (only for tests of the entry tools on the same maschine) has a few problems. Error messages without explain. regards Rudi. George Pontis schrieb in Nachricht ... >Has anyone got Foundation M1.4 DynaText Browser working with Windows NT >4.0 (SP3). I am using NTFS, which may not be a tested configuration. All >looks good until I try to open something. For example, Libraries Guide" >under "Xilinx Books CD". The CDROM spins for a second, and then I get the >message "Cannot open book ...". The same thing happens for all books >whether on CD or disk. > >I have checked (and corrected) the paths in dynatext.ini, and they all >make sense. With some very quick system file monitoring I see that >DynaText is playing fast and loose with file and directory names. For >example, it creates a directory using mixed upper/lower case names, and >then accesses it using a different combination of upper and lower case. >Not that this shouldn't work, but it is the type of thing that makes me >suspect a problem when run under NTFS. > >It may be worth mentioning that Dynatext worked OK on this system in >M1.3. >-- >George Pontis > >(Replies to geo at z9 dot com.)Article: 11115
On Sun, 19 Jul 1998 10:42:35 -0400, APS <resp@associatedpro.com> wrote: >Has anyone done any CRC-16 implementations in an FPGA? I am looking for >the CRC-CCITT implementaton in particular. Any help or pointers to >information at all would be appretiated? The first problem here is the phrase 'CRC-CCITT'. I don't know who invented this term (it doesn't seem to have been the CCITT), and what specifically they meant, but I take it to mean some subset of V41 and V42 (CCITT Blue Book, Volume VIII, Fascicle VIII.I, recommendations V41 and V42, ISBN 92-61-03661-9). V41 and V42 agree on a polynomial, but recommend different preset values for the shift register. I think the most common implementation is to preset the transmitter to all 1's, to invert the output, and for the receiver to check for 0x1D0F (the V42 'typical implementation'). If you don't want to do a parallel version, then the diagrams in the spec are all you'll need. If you want a parallel version, you'll have to decompose the polynomial into a parallel form. This is pretty straightforward. One very useful reference is one of AMD's TAXI app notes, which I've unfortunately lost. You could also look up an EDN article by Krishna Rallapalli (EDN, Sept.5/1978). I think this describes an old Fairchild chip (74F401?). I've also got an old article by Jack Ganssle (1991) - I don't know what the source is; probably EDN or Byte. The next problem is that the CCITT describes a bit-serial algorithm, and so there's an implicit endianism problem when you convert to parallel. The articles I've seen generally ignore this (Ganssle's is particularly bad, and wrong), and so they result in different implementations (for instance, the receiver has to check for 0xF0B8 instead of 0x1D0F). A related problem is whether to transmit the high byte of the result first, or second. The answer's easy if you've actually got a bit- serial transmission medium - everything has to be bit-big-endian (X25, for example, normally sends its data fields little-endian, but sends the checksum big-endian). However, if you're not responsible for the complete system, the important thing is to check that everyone agrees on the transmission format and check value - there's a good chance that the other guy will have got it wrong. The actual parallel hardware's pretty trivial. You can trade off the number of delay levels against the logic complexity but, IIRC, you'll end up with a total of 20-25 two, three, and four-in xor's. Evan (ems@nospam.riverside-machines.com)Article: 11116
I'm in a situation where I need to implement a high-speed multiplier. It's going to be a 12x12 unsigned multiply, producing a 24 bit result. Would like to see if it can be done in 5 clock cycles or less. (Clock cycle will be in the MHz range). I'm targeting a Xilinx XC4062XL part. I'm in the process now of trying to debug the interface to a Xilinx CORE-gen'ed multiplier that does the job in 5 clocks. Any inputs welcomed. I've already had someone suggest looking at the Xilinx app note on a constant coefficient multiplier. Thanks, BobArticle: 11117
George, Mine works fine under NT. I too am using NTFS. I installed the documention disk on my hard drive. I get book listings under Xilinx Books and Broswer documentation only. The others have blank book lists. I open books successfully. Mine worked fine right out of the box, so I can't give you tips on what to fix. George Pontis wrote: > Has anyone got Foundation M1.4 DynaText Browser working with Windows NT > 4.0 (SP3). I am using NTFS, which may not be a tested configuration. All > looks good until I try to open something. For example, Libraries Guide" > under "Xilinx Books CD". The CDROM spins for a second, and then I get the > message "Cannot open book ...". The same thing happens for all books > whether on CD or disk. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 11118
Does anyone happen to know what has happened to either Crosspoint Solutions or Concurrent Logic? I'm currently doing some research, and can't seem to find anything out about them. Chances are that they went bust or got taken over, but a definate confirmation would be useful. My thanks in advance... Edward Pickering UMISTArticle: 11119
Does anyone happen to know what has happened to either Crosspoint Solutions or Concurrent Logic? I'm currently doing some research, and can't seem to find anything out about them. Chances are that they went bust or got taken over, but a definate confirmation would be useful. My thanks in advance... Edward Pickering UMISTArticle: 11120
Does anyone happen to know what has happened to either Crosspoint Solutions or Concurrent Logic? I'm currently doing some research, and can't seem to find anything out about them. Chances are that they went bust or got taken over, but a definate confirmation would be useful. My thanks in advance... Edward Pickering UMISTArticle: 11121
Ray Andraka <no_spam_randraka@ids.net> wrote: > There are 4 devices that are currently on the market that I am aware of > that handle partial reconfiguration: Atmel AT40K series, Atmel AT6K > series, Dynachip DL6K series and Xilinx 6200. Motorola's part could too, > but they just killed their FPGA line a few weeks ago, and National > Semiconductor has a series of parts that do it, but so far they are not > selling them to the general public. Lucent Orca parts are partially reconfigurable. Each configuration frame has an 11-bit address which provides random access to the configuration. There are 500 to 1500 frames per chip.Article: 11122
Bob, I've got a 12x12 in unsigned, signed and partially signed flavors that is pipelined 5 clocks and is good to about 50 MHz in a 40xxE-2. The footprint fits in a 14hx13w rectangle. I believe the xilinx logic core generator generates one that is similar. The multiplier uses the technique you learned for long hand multiplication in grade school, in that one input is multiplied separately by each 2-bit 'digit' of the other input, and then those partial products are summed with the appropriate amounts of shift. Each partial multiplies the other input by either 0, 1, 2, or 3 depending on the value of the two bits. The first stage of my pipeline unconditionally computes 3x the A input by adding a shifted version of the input to itself. This stage also passes the 1x A input delayed by a clock. The next level in the pipeline is a set of 4:1 multiplexers controlled by pairs of bits in the B input. The multiplexers select either 0, the 1x A input, the 1x A input left shifted (2x), or the 3x A input. Thus the multiplexers with the common 3x logic forms a set of fast cheap 2xn multipliers. This by the way is where mine differs from the xilinx logicore macro (the xilinx macro may have since been updated). The xilinx macro rolls the 3x adder into the multiplexer, which results in slightly less area, but also reduces the performance by about 15% due to the high fanout and carry chain being in the same combinatorial path. The remaining 3 pipeline stages make up a registered adder tree that simply adds the partial products from the muxes together to obtain the full monty. If you only need to do the multiplication at around 1MHz, and you can obtain a higher clock why not use a radix serial by parallel multiply? It would take considerably less real estate to do. Bob Myers wrote: > I'm in a situation where I need to implement a high-speed > multiplier. It's going to be a 12x12 unsigned multiply, > producing a 24 bit result. Would like to see if it can > be done in 5 clock cycles or less. (Clock cycle will be > in the MHz range). > > I'm targeting a Xilinx XC4062XL part. I'm in the process > now of trying to debug the interface to a Xilinx CORE-gen'ed > multiplier that does the job in 5 clocks. > > Any inputs welcomed. I've already had someone suggest > looking at the Xilinx app note on a constant coefficient > multiplier. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka The Andraka Consulting Group is a digital hardware design firm specializing in high performance FPGA designs for signal processing, computing and control applications.Article: 11123
Edward Pickering wrote: > Does anyone happen to know what has happened to either Crosspoint > Solutions or Concurrent Logic? > > I'm currently doing some research, and can't seem to find anything out > about them. Chances are that they went bust or got taken over, but a > definate confirmation would be useful. > > My thanks in advance... > > Edward Pickering > UMIST Concurrent sold to national semiconductor and Atmel (I don't recall the legal stuff). Any way, the Atmel 6K devices are the concurrent architecture with a few minor changes. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 11124
Don Husby wrote: > Ray Andraka <no_spam_randraka@ids.net> wrote: > > There are 4 devices that are currently on the market that I am aware of > > that handle partial reconfiguration: Atmel AT40K series, Atmel AT6K > > series, Dynachip DL6K series and Xilinx 6200. Motorola's part could too, > > but they just killed their FPGA line a few weeks ago, and National > > Semiconductor has a series of parts that do it, but so far they are not > > selling them to the general public. > > Lucent Orca parts are partially reconfigurable. > Each configuration frame has an 11-bit address which > provides random access to the configuration. There are 500 to 1500 frames > per chip. See, even I learn something new everyday! -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka
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