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
Where are there some really easy point and click tutorials for ModelSIM?Article: 74676
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:417002AD.A8651DD2@yahoo.com... > Does Altium use the same cable with both the Spartan 3 and the Cyclone > version of the boards? Are the same parallel port pins used by the > Quartus and the ISE software? Or did they design the cable to > accomodate both sets of connections in one cable? > I think that the cables are the same (straight connect parallel ribbon cables) but the pin designations at the PC end are different. This is because the drivers for the cable are located on the evaluation board itself and not in the cable connector. The Cyclone eval board looks like a ByteBlaster cable to the software on the PC and the Xilinx eval board looks like an ISE compatible cable (eg. Parallel 3 cable).Article: 74677
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:417008B1.49FA6E39@yahoo.com... > I had noticed a few issues with the Altium schematics for their FPGA > boards earlier. But I was looking closely at the Altera version of the > schematic and realize that they have actual wiring flaws in the > drawings! The PP_HARD_TDI signal has no connection to the parallel port > connector and the PP_HARD_TDO signal runs over top of a resistor and may > actually be shorting two nets!!! Isn't Altium selling the eval board to > get you to evaluate their tools including schematic capture and board > layout??? This is not much of a recommendation. > > On the page with the FPGA many of the net lables are turned around and > upsidedown and lie over top of other net labels so that they can not be > read. Maybe it's just me, but I would not even consider buying software > that the makers find hard to use. I don't' think I can even make these > mistakes with Orcad. The software is not that "capable". > It looks like that is just an artifact of a bad translation to Adobe Acrobat format (.pdf). The original Altium DXP schematics don't have these problems: http://www.altium.com/dxpcentral/LiveDesign/ReferenceDesigns/LiveDesignEvaluationBoard(EB1EB2).zipArticle: 74678
Hi Eric, > I realize a blanket statement 71 LE's (approx. =) 40 Slices, is totaly > dependant on how the code is sysnthesized. > > But is a approximate 1 Slice = 2 LE's a pretty close all around > estimate. Yes, that's a good 1st order estimate. We believe that 1 Slice is equal to about 1.8 LEs based on average results across a suite of designs, but mileage will vary from design to design -- this lines up well with your result though. One thing you should do is ensure that the CAD tool is trying to use as few LEs (and slices for Xilinx) as possible. When you are not filling up the device, Quartus will not try too hard to put LUTs and FFs into the same LE -- if there's any chance it will hurt rather than help timing, it will avoid it. When you start filling the device close to capacity, Quartus will try to pack more aggressively. This is the default "auto" setting for register packing. To artificially force Quartus to pack as aggressively as possible into LEs, go to the menu Assignments/Settings... select the Fitter Settings tab, and click the "More Settings..." button. There is a setting called "Auto Packed Registers -- Max II". Setting this to Minimize Area w/Chains will cause the most aggressive packing. Also, under the Analysis & Synthesis Settings tab, you can try out the "area" optimization technique which heuristically cares more about area than delay, though doesn't always necessarily reduce LE count. Regards, Paul Leventis Altera Corp.Article: 74679
"Guitarman" <ericjohnholland@hotmail.com> a écrit dans le message de
news:90282e35.0410151112.77a87654@posting.google.com...
> Hello All,
>
> I've been designing with Xilinx FPGAs for a while so I'm used to the
> "Slice" concept. I'm looking at Altera's Max II as a nice possible
> solution for a design.
>
> I took my VHDL code and it synthesized to 40 Slices in a Spartan III.
> Then I took the same code and sythesized it for a Max II (using
> Quartus II now) and it was 71 LE's.
>
> I realize a blanket statement 71 LE's (approx. =) 40 Slices, is totaly
> dependant on how the code is sysnthesized.
>
> But is a approximate 1 Slice = 2 LE's a pretty close all around
> estimate.
>
> Thanks
> Eric
I disagree, both architectures are different, you can't compare it in this
way
have how many slices into the following code ?
.....
DI : in std_logic;
DO : out std_logic;
CLOCK : in std_logic;
.....
.......
signal temp: std_logic_vector(15 downto 0);
......
begin
Demo : process(CLOCK)
begin
if rising_edge(CLOCK) then
temp<= temp(14 downto 0) & DI;
end if;
end process Demo;
DO <= temp(15);
....
Article: 74680Hi Vax, First, I should point out that Altera's mature MAX 7000 family is likely sufficient and widely available. The MAX 7000S is a 5.0V device with up to 256 macrocells. The MAX 7000AE is a 3.3V device with up to 512 macrocells. Both are available in a wide array of cheap, easy-to-use packages. The new low-cost Max II family from Altera also meets many of your requirements. Max II is 3.3V compatible (both power rail voltage and I/O voltage). The EPM570 device offers 570 LEs, or roughly 440 macrocells. It is supported by the free Quartus II Web Edition software, available from our web site. There are three packages: a 100-pin TQFP (with 76 user I/Os), a 144-pin TQFP (with 116 user I/Os), and a 256-pin FBGA (with 160 user I/Os). The downside is that you can't buy the EPM570 today -- only the EPM1270 is available. But it is shipping in a pin-compatible 144-pin TQFP, so you could prototype with it and plug in a EPM570 in early 2005 when it is available. I don't know the unit prices of any of our chips so I can't help you out there. If we get the Web Edition software from www.altera.com, you can try out all of our CPLD families to see how they do for density & performance. Your VHDL should work (provided it is generic) in any of our devices. > BTW, is it easy to move a CPLD design (VHDL) to FPGA? It has mostly adders > (5 MHz or lower) and state machines (20MHz). Thanks. If so, would you also > let me know what FPGA family to look at, with those requirements applied? Max II's core fabric is more like an FPGA -- it uses LUT-based Logic Elements (LEs) instead of AND-OR macrocells. It also features a segmented, island-style routing architecture instead of the global fabrics found in older CPLD families. This family is perfect for you needs. Generic VHDL should run push-button on Max II, or any other CPLD/FPGA product from pretty much any vendor. Just change the target device & push compile! And the speed targets you mention are slow by modern FPGA/CPLD standards, so they sound doable. Good luck, Paul Leventis Altera Corp.Article: 74681
>One thing you should do is ensure that the CAD tool is trying to use as few >LEs (and slices for Xilinx) as possible. When you are not filling up the >device, Quartus will not try too hard to put LUTs and FFs into the same >LE -- if there's any chance it will hurt rather than help timing, it will >avoid it. When you start filling the device close to capacity, Quartus will >try to pack more aggressively. This is the default "auto" setting for >register packing. What would make the timing better if the LUT and FF are not packed in the same LE? I'm assuming that there is a very good path connecting the LUT/FF in the same LE because it is such a common case. What makes not using that faster? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 74682
This probably ought to be in the FAQ... then again perhaps there isn't a clear answer to this, since the definition of "FPGA" is a bit fuzzy to begin with. - a -- I wrote my own mail server and it still has a few bugs. If you send me a message and it bounces, please forward the bounce message to megacz@gmail.com. Thanks!Article: 74683
John Williams wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:417008B1.49FA6E39@yahoo.com... > > I had noticed a few issues with the Altium schematics for their FPGA > > boards earlier. But I was looking closely at the Altera version of the > > schematic and realize that they have actual wiring flaws in the > > drawings! The PP_HARD_TDI signal has no connection to the parallel port > > connector and the PP_HARD_TDO signal runs over top of a resistor and may > > actually be shorting two nets!!! Isn't Altium selling the eval board to > > get you to evaluate their tools including schematic capture and board > > layout??? This is not much of a recommendation. > > > > On the page with the FPGA many of the net lables are turned around and > > upsidedown and lie over top of other net labels so that they can not be > > read. Maybe it's just me, but I would not even consider buying software > > that the makers find hard to use. I don't' think I can even make these > > mistakes with Orcad. The software is not that "capable". > > > > It looks like that is just an artifact of a bad translation to Adobe Acrobat > format (.pdf). > > The original Altium DXP schematics don't have these problems: > http://www.altium.com/dxpcentral/LiveDesign/ReferenceDesigns/LiveDesignEvaluationBoard(EB1EB2).zip It looks like these are Altium software files of some sort, so I can't view them. But the issues I saw in the schematic PDF files are not the sort of problem that Acrobat could cause. I guess they are just an older version with some bugs. I noticed that on the Altera board schematic, the PP_HARD_TDI signal is not even connected to the parallel port connector and the PP_HARD_TDO signal is not connected correctly, it looks like it shorts across the pullup resistor. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 74684
Hal Murray wrote: > > >One thing you should do is ensure that the CAD tool is trying to use as few > >LEs (and slices for Xilinx) as possible. When you are not filling up the > >device, Quartus will not try too hard to put LUTs and FFs into the same > >LE -- if there's any chance it will hurt rather than help timing, it will > >avoid it. When you start filling the device close to capacity, Quartus will > >try to pack more aggressively. This is the default "auto" setting for > >register packing. > > What would make the timing better if the LUT and FF are not packed > in the same LE? > > I'm assuming that there is a very good path connecting the LUT/FF in > the same LE because it is such a common case. What makes not > using that faster? He is not talking about a LUT and FF that are connected, he means ones that are separate. Like a FF with the D input connected to the output of another FF and a LUT that has its output going to another LUT only. Unless there is a shortage of IO in the LAB, they can share the same LE. Same thing in the Xilinx slice. Due to crowding of the routing, it may result in a faster design to keep them separate. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 74685
It's a matter of time. I have a lot to do inside this FPGA and outside it on the board. I'am more aware about board design than FPGA. So if I can have this part or some clues to begin quickly, It's welcome. I have no speed or resource constrain, and I will use a Spartan FPGA. Thank you "John_H" <johnhandwork@mail.com> a écrit dans le message de news:aAZbd.33$vk2.2430@news-west.eli.net... > Since BCD to Bin is the easy direction (a bunch of adders), why is it you > don't care to try it yourself? > Are you limited by speed? Latency? Resources? CPLD rather than FPGA > implementation? How many digits do you need? > > "JPR" <jpr@nospam.com> wrote in message > news:41705b34$0$29012$afc38c87@news.easynet.fr... > > Hi everybody, > > > > I'am searching for 4 digits BCD (=16 bits) to BIN convertor. If possible > in > > VHDL. > > > > Thanks > >Article: 74686
I have stoped doing homework 12 years ago. "Rich Webb" <bbew.ar@mapson.nozirev.ten> a écrit dans le message de news:l4r0n0hiurm06votk64kl3jvh9sibvpnlq@4ax.com... > On Sat, 16 Oct 2004 00:04:22 GMT, "John_H" <johnhandwork@mail.com> > wrote: > > >Since BCD to Bin is the easy direction (a bunch of adders), why is it you > >don't care to try it yourself? > >Are you limited by speed? Latency? Resources? CPLD rather than FPGA > >implementation? How many digits do you need? > > (probably just enough to get his homework done) l;-) > > -- > Rich Webb Norfolk, VAArticle: 74687
modelsim isn't really that difficult to use... its the VHDL or verilog testbench that's the bugger. Simon "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:10n10gn1546dba4@corp.supernews.com... > Where are there some really easy point and click tutorials for ModelSIM? > >Article: 74688
why not just type it in.....
case n is
when '4' => bin <= X"4";
..
..
..
or what ever ... just let the compiler do all the dirty work :-)
Simon
"JPR" <jpr@nospam.com> wrote in message
news:4170d06f$0$199$afc38c87@news.easynet.fr...
> It's a matter of time. I have a lot to do inside this FPGA and outside it
on
> the board.
> I'am more aware about board design than FPGA.
> So if I can have this part or some clues to begin quickly, It's welcome.
> I have no speed or resource constrain, and I will use a Spartan FPGA.
>
> Thank you
>
> "John_H" <johnhandwork@mail.com> a écrit dans le message de
> news:aAZbd.33$vk2.2430@news-west.eli.net...
> > Since BCD to Bin is the easy direction (a bunch of adders), why is it
you
> > don't care to try it yourself?
> > Are you limited by speed? Latency? Resources? CPLD rather than FPGA
> > implementation? How many digits do you need?
> >
> > "JPR" <jpr@nospam.com> wrote in message
> > news:41705b34$0$29012$afc38c87@news.easynet.fr...
> > > Hi everybody,
> > >
> > > I'am searching for 4 digits BCD (=16 bits) to BIN convertor. If
possible
> > in
> > > VHDL.
> > >
> > > Thanks
> >
> >
>
>
Article: 74689Another word of warning... Altium also said their FPGA Software would work without the FPGA development boards... just as the boards should work without Altium.. . unfortunately... there's a slight hic-up... Nextar needs to talk to an Altium board to start-up. opps... As a long time user of Protel and Altium I support them.. I would just like to point out that you should be very cautious... You might want to ask on the DXP tech forum for answers (forums altium com) just add dots. There are a lot of users out there... some might be able to get the board working with Quartus or Xilinx. Otherwise I would have grave doubts. Simon "rickman" <spamgoeshere4@yahoo.com> wrote in message news:416FF5C0.2703E83A@yahoo.com... > Arash Salarian wrote: > > > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > news:416EE08B.443D61B5@yahoo.com... > > > I have not been able to > > > confirm that the Altium board is usable without the Altium software > > > (demo version has a 30 day license only). There are JTAG ports on the > > > board, but the use a connector for the PC parallel port. I also don't > > > understand why there are *two* of them, soft and hard. > > > > I remember to read it somewhere in the Altium site that says that the boards > > WORK without Altium software. Also, by looking at the schematics you can see > > that in the Altera's version, they say the interface is compatible with > > ByteBlaster and for the Xilinx version it has been written to be compatible > > with ISE. > > I have not seen that. I downloaded the Xilinx version info and did not > see anything relevant in the manual. In particular, my concern is how > to acutally hook the board up and get it to work without the Altium > tools. The connector on the eval board is not standard and is designed > to work with their cable and PC software talking to the parallel port. > I belive it will require Altium software to make this work. >Article: 74690
"Dan DeConinck of PixelSmart": > I have been unable to generate the CPU burst read. My code was written with > DEBUG under DOS > This code moves 255 16bit words from my PCI target to the CPU main memory > > Mov CX, 00FF > REPZ > MOVSW > > The code successfully executes BUT it is done as individual transactions. > Each transaction is a single double word read. If you can't mark that block as cacheable, the only thing you can do will be to use instructions, that transfer a multiple of bus size at once: mov eax,[PCI_addr] // move 32 bits movq mmx0,[PCI_addr]; // move 64 bits movps xmm0,[PCI_addr]; // move 128 bits For writes, CPU may combine such moves. For reads, the PCI-controller needs to know, what the final dataphase is, before that dataphase is up, I guess. Gruss Jan BrunsArticle: 74691
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:10n10gn1546dba4@corp.supernews.com... > Where are there some really easy point and click tutorials for ModelSIM? It comes with quite a good introductory tutorial. LeonArticle: 74692
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:4170CF52.A1F9C9B5@yahoo.com... > > > > The original Altium DXP schematics don't have these problems: > > http://www.altium.com/dxpcentral/LiveDesign/ReferenceDesigns/LiveDesignEvaluationBoard(EB1EB2).zip > > It looks like these are Altium software files of some sort, so I can't > view them. But the issues I saw in the schematic PDF files are not the > sort of problem that Acrobat could cause. I guess they are just an > older version with some bugs. I noticed that on the Altera board > schematic, the PP_HARD_TDI signal is not even connected to the parallel > port connector and the PP_HARD_TDO signal is not connected correctly, it > looks like it shorts across the pullup resistor. > My guess is that the PDF files that are posted on their web site were not created correctly from the original schematics. The original schematic of the Altera board parallel port interface shows PP_HARD_TDI connected through a 100 ohm resistor to parallel port pin 8 (D6). It shows PP_HARD_TDO connected through a 100 ohm resistor to parallel port pin 11 (BUSY).Article: 74693
Hi Hal, Rick: > > What would make the timing better if the LUT and FF are not packed > > in the same LE? > He is not talking about a LUT and FF that are connected, he means ones > that are separate. Like a FF with the D input connected to the output > of another FF and a LUT that has its output going to another LUT only. > Unless there is a shortage of IO in the LAB, they can share the same > LE. Rick's got it mostly right. The Stratix/Cyclone/Max II LE/ALMs can have a number of register/LUT pairings: 1. LUT feeds FF 2. FF feeds LUT 3. Unrelated FF and 3-input LUT 4. FF->FF connection from adjacent LE and a 4-input LUT (a register chain) For example, we could pack an 8-bit shift register in with 7 4-LUTs and 1 3-LUT to form 8 LEs. As Hal observed, it seems like doing #1 (or #2) is always a win. If you look at one FF, in our architecture we can choose to pack it with its fan-in (#1) or fan-out (#2). For example, if the critical path of the design is on the output of the FF, through only one of its LUTs, using packing #2 is the better choice for that flop. So there is an interesting optimization problem here. Some of the LEs created by #1 or #2 will have two seperate LE outputs (the Flop and the LUT) in the event that the FF/LUT connection is not single fanout. In theory, these multiple output LEs create a bit more routing pressure and so you may hurt timing more by making one than you do by bringing the FF and LUT together. But our routing architecture has been designed to tolerate aggressive packing. One way that using packing #1 or #2 can be sub-optimal is in the event where the flop really wants to be placed somewhere in-between all the things that it feeds and feeds it. Packing it with either source or destination might help one path, but hurt others more than if you just left the FF in a seperate LE and thus were free to move it where it wanted to be during placement. Now, when you look at #3, you must be intelligent in how you pack. If you take two unrelated functions that otherwise would want to be in opposite corners of the chip and put them together, you can hurt timing. Also, as Rick points out, LEs of this type will have 4 inputs and 2 outputs; if you make many of them you can start stressing the routing and this can lead to lower performance. Incidentally, this packing problem also arises on Stratix II when it comes to packing multiple functions into an ALM -- if they are unrelated, you must choose pairings wisely to not hurt performance. Packing #4 is particularly nasty from a CAD perspective. Creating these packings implies a group of LEs that must all be placed in the same LAB (register chain) and must move as a group. This further restricts placement and routing choices, and thus has the largest chance of being a net negative. But it can also help reduce the number of LEs in some designs. Note: The more your pack together into LEs, the closer in general you can place the LEs of a design, so doing these packings can also help performance :-) >Same thing in the Xilinx slice. Due to crowding of the routing, it > may result in a faster design to keep them separate. The trade-offs are likely different here. The VII slice has some FF packing capabilities. It can do #1, but #2 requires use of local routing (I think). It's not clear to me from the slice diagram whether packing #3 can be done. #4 is not possible. Also, I'm not sure how well the architecture responds to slices with multiple outputs (using the Y and Q outputs at the same time). If it was not architected for heavy use of both outputs, there could be more routing/performance trade-off here. This is all speculation. What I do know is when we compare half-slice vs. LE counts on a suite of designs, we find a ~9% advantage for Quartus + LEs over ISE + slices. We believe that the primary reason for this difference is the increased flop packing density available in the Altera LE. Regards, Paul Leventis Altera Corp.Article: 74694
In article <4170D026.5193E181@yahoo.com>, rickman <john@bluepal.net> wrote: >Hal Murray wrote: >> I'm assuming that there is a very good path connecting the LUT/FF in >> the same LE because it is such a common case. What makes not >> using that faster? > >He is not talking about a LUT and FF that are connected, he means ones >that are separate. Like a FF with the D input connected to the output >of another FF and a LUT that has its output going to another LUT only. >Unless there is a shortage of IO in the LAB, they can share the same >LE. Same thing in the Xilinx slice. Due to crowding of the routing, it >may result in a faster design to keep them separate. Not just routing, but also placement: The separate pieces (FFs, LUTs etc) are not placed independantly, but are packed together and then placed. Thus if unrelated logic is packed together inappropriately, the placement for the packed component may be significantly worse than if each component was placed separately. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 74695
The answare is
1 slice into a Spartan 3
16 LE into a MAX-II
Can you compare this architectures as 1 Slice = 2 LE's ?
Walter.
"Walter Gallegos" <walter@chasque.apc.org> a écrit dans le message de
news:10n13v2dqalbv6a@news.supernews.com...
>
> "Guitarman" <ericjohnholland@hotmail.com> a écrit dans le message de
> news:90282e35.0410151112.77a87654@posting.google.com...
> > Hello All,
> >
> > I've been designing with Xilinx FPGAs for a while so I'm used to the
> > "Slice" concept. I'm looking at Altera's Max II as a nice possible
> > solution for a design.
> >
> > I took my VHDL code and it synthesized to 40 Slices in a Spartan III.
> > Then I took the same code and sythesized it for a Max II (using
> > Quartus II now) and it was 71 LE's.
> >
> > I realize a blanket statement 71 LE's (approx. =) 40 Slices, is totaly
> > dependant on how the code is sysnthesized.
> >
> > But is a approximate 1 Slice = 2 LE's a pretty close all around
> > estimate.
> >
> > Thanks
> > Eric
>
> I disagree, both architectures are different, you can't compare it in
this
> way
> have how many slices into the following code ?
> .....
> DI : in std_logic;
> DO : out std_logic;
> CLOCK : in std_logic;
> .....
> .......
> signal temp: std_logic_vector(15 downto 0);
> ......
> begin
>
> Demo : process(CLOCK)
> begin
> if rising_edge(CLOCK) then
> temp<= temp(14 downto 0) & DI;
> end if;
> end process Demo;
>
> DO <= temp(15);
> ....
>
>
>
>
Article: 74696ccon67@netscape.net (Marlboro) wrote in message news:<e3fd5378.0410151004.4015287c@posting.google.com>... > Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in > > >shankar.sb@gmail.com (Shankar B) wrote in message > > >> > >mete wrote: > > >> > >> Is there method that is more efficient than regular division for > > >> > >> calculating modulus ? > > [snip] I wrote: > > >John (always interested in these type circuits) > > > > You might be interested in this thread: > > http://groups.google.com/groups?threadm=18c289aa.0304230854.6897fb3b%40posting.google.com > > which discusses a combinatorial circuit for evaluating a ten bit > > number mod 3 in a single CLB. Thanks Allan, I shoulda googled first > It's even simpler for mod 0, isn't it? IHMO, ingeneral cases you > can't avoid the DIV operation or some agorithm similar to that, > cheers, Reducto ab absurdum? Here's the similar algorithm/circuit, as best I can work out this morning... Shankar wrote me about my previous post, pointed out I was a little incomplete in my explanation (sorry, it was late, it was after a long day at work, and that post was the last thing I did before heading home). The MAIN point is that mod distributes over addition, and can be solved using distributed arithmetic. Gory details (I waved my hands too much last post): Some definitions: B: Base for modulus b: number of bits to represent B in binary N: Number to take mod of n: number of bits in N Exclude special cases such as B = 2^k, 2^k - 1, 2^k + 1, which have neat tricks that can be used, as Allan pointed out in previous mod thread. When n is very large and b is somewhat large, mod(N,B) can be generated (for fixed B) as follows: 1) Group the bits of N into a lower group, G0, consisting of b LSBs of N, and a set of 4-bit upper groups to feed LUTs: L0, L1, ..., Lr, ..., LR where R = ceil((n-b)/4) - 1. The top group, LR, may have <4 bits. 2) Each of the upper groups, Lr, feeds an array of b LUTs to lookup the values MOD(i*2^(4*r+b),B) for i = 0..15. Call the LUT outputs M0, M1, ..., MR. 3) Sum: S = G0 + M0 + M1 + ... + MR. The result S will be at most (R+2)*B, and will thus have at most b + ceil(log2(R+2)) bits. 4) If R > 0, let N <= S and repeat 1..3. 5) R = 0, subtract: F = S - B 6) If F is negative, MOD(N,B) = S, else MOD(N,B) = F As usual, pipeline to taste. Not quite as easy as 1,2,3, but a little easier than division. Hmmm. Starting this exploration, I was thinking of arbitrary divisor; fixed division can be approximated similarly to steps 2 and 3 (inverse multiplication distributes over addition). So slightly worse than division. But mod generally uses smaller adders at step 3). But division ends at step 3). So it depends on definition of complexity, more circuitry, or more levels...(Sorry to be talking to myself here, just working it out). Hope no one was bored, I was annoyed at my previous post for being fuzzy in the details! Allan, I recall for 2^k - 1, break into k-bit groups, add, repeat as req'd. How about 2^k + 1? I'm lazy after the above exposition. Anyone care to speak to interesting H/W applications for mod? Regards All, JohnArticle: 74697
I've downloaded the Webpack 6.3, and found that XST still lacks support for Verilog define-arguments. `define MINIMUM2( x, y ) ( ((x)>(y)) ? (y) : (x) ) parameter IN_BUS = 16; parameter OUT_BUS = 8; parameter DATA_BUS = `MINIMUM2( IN_BUS, OUT_BUS ); ... If I try to synthesize this, Xilinx gives me a strange syntax error. It's obviously stumped by my `define macro. Thankfully, I rarely use these constructs in RTL-code, but it's convenient for certain expressions and bit-manipulations. ... And support for the system-tasks $signed() and $unsigned() would be nice, too!Article: 74698
JPR wrote:
>
> Hi everybody,
>
> I'am searching for 4 digits BCD (=16 bits) to BIN convertor. If possible in
> VHDL.
>
> Thanks
You don't say if it is to be fully combinatorial or if it can use
multiple clock cycles. A combinatorial approach requires 10 adders, not
all of 16 bits. If you can use mulitple clock cycles, the amount of
logic can be greatly reduced. Here is a clocked version that requires
N+1 clock cycles to produce a result. I will let you add the
multiplexor at the input if needed as well as the control logic to count
to five. This can also be shortened to N clock cycles if needed.
slvxx is a subtype of std_logic_vector of range xx-1 downto 0.
signal bin_value : slv16; -- output binary value
signal digit : slv4; -- input decimal digit
signal start : std_logic; -- reset the counter to zero to start
signal load_digit : std_logic; -- add the next digit into the register
process (clk, reset)
begin
if (reset = '1') then
bin_value <= (others => '0');
elsif (rising_edge(clk)) then
if (start = '1') then
bin_value <= (others => '0');
elsif (load_digit = '1') then
bin_value <= to_slv( ( (unsigned( bin_value) sll 3) +
(unsigned( bin_value) sll 1) +
unsigned( digit)
), length'bin_value);
end if;
end if;
end process;
I have not tested this code, so no guarantees... :)
If you need more done on this email me.
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 74699John Williams wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:4170CF52.A1F9C9B5@yahoo.com... > > > > > > The original Altium DXP schematics don't have these problems: > > > > http://www.altium.com/dxpcentral/LiveDesign/ReferenceDesigns/LiveDesignEvaluationBoard(EB1EB2).zip > > > > It looks like these are Altium software files of some sort, so I can't > > view them. But the issues I saw in the schematic PDF files are not the > > sort of problem that Acrobat could cause. I guess they are just an > > older version with some bugs. I noticed that on the Altera board > > schematic, the PP_HARD_TDI signal is not even connected to the parallel > > port connector and the PP_HARD_TDO signal is not connected correctly, it > > looks like it shorts across the pullup resistor. > > > > My guess is that the PDF files that are posted on their web site were not > created correctly from the original schematics. > > The original schematic of the Altera board parallel port interface shows > PP_HARD_TDI connected through a 100 ohm resistor to parallel port pin 8 > (D6). > It shows PP_HARD_TDO connected through a 100 ohm resistor to parallel port > pin 11 (BUSY). I don't want to beat a dead horse, but it is not very common to goof up making a PDF file. The Acrobat software installs a printer driver that is used just like a printer, but it produces a PDF file; WYSIWYG. I use this very often and I never have any issues with it. I have never seen it add lines, remove lines or turn text around. These mistakes were either due to someone printing out an old version of the drawings or possibly the Altium software not printing correctly. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
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