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 30/10/2013 14:50, Nikolaos Kavvadias wrote: > Dear all, > > HercuLeS by Ajax Compilers, Inc. (http://www.ajaxcompilers.com) is an easy to use high-level synthesis (HLS) environment for the automatic translation of algorithms to hardware. HercuLeS is suitable for both hardware-oriented and software-minded engineers. > > You can download the FREE version of HercuLeS for Windows 7 (64-bit) and Linux (32-bit and 64-bit) from here: > > http://www.nkavvadias.com/temp/index.php > > No registrations, no emails, no additional downloads, no fuss! > > Just get the file, read the instructions from this page, and you are set! > > Compared to the BASIC and FULL versions, there are some features intentionally missing from the FREE version; please consult the HercuLeS feature matrix for full details: > > http://www.nkavvadias.com/hercules/hercules-feature-matrix.html > > > Best regards, > Nikolaos Kavvadias > CEO > Ajax Compilers > Kornarou 12 Rd, Nea Ampliani, > 35100 Lamia > Greece > Hi Nikolaos, From the examples it looks like a promising piece of technology and I am always amazed what a single developer can write. However, I would strongly suggest you get a few beta testers to go through the setup and more importantly the usage model of HercuLeS since I think it needs some work. Thanks for making a free version available, Hans www.ht-lab.comArticle: 155976
Hi Hal, On 31/10/2013 21:23, Hal Murray wrote: > In article <l4k5rr$nqs$1@dont-email.me>, > rickman <gnuarm@gmail.com> writes: > >> Ever since I have not trusted the tools 100%. > > Software geeks have been fighting compiler bugs for a long long time. it does not take 'software geeks' to fight bugs. It takes a process of development and verification that has a level of complexity that is certainly beyond anything that 'software geeks' can deem to conceive alone. The process is also full of compromises which are constraints driven and pitfalls as well. For further readings refer to [1]. > The thing that makes FPGA timing bugs so nasty is that you can't > reasonably check the output. I'm not sure what makes you think that you cannot 'reasonably' check the output. A synthesis tool provide a netlist and the netlist is verifiable. A P&R tool provides a bitstream which is verifiable. The problem is that, unfortunately, being tools proprietary software with a non-standardized output format, is difficult for the *end user* to check. But the main developers of the tools can certainly check at each level of complexity they want, it is all a matter of 'pain vs. gain'. In the open source software world (without wandering even further in the 'libre' software world) there's a level of peer-review that is orders of magnitude higher than in proprietary software and that is why open software is - by far - less buggy than proprietary software. Now try to convince any EDA company to release their source code... > With a compiler, you can look at the > instructions it produces. Not knowing the instruction set is exactly the same as not knowing the bitstream format for an FPGA. Having said that, even assuming you know how the instruction set looks like, there's still a lot of work to 'reasonably' verify the tool. Be also aware that the level of 'reasonableness' is what companies have clear in mind, considering that complex bugs are difficult to find (meaning they cost money to the company), they decide what is the level of 'reasonableness' they pick according to their market. > With a PCB router, you can eyeball the gerbers. Complex designs need a verification plan. There's no eyeballing that can help you. With a verification plan you can minimize the amount of time you spend on the bench to debug it, but it's all matter of the amount of risk you want to deal with. > Many years ago, I made a list of all the possible places that could > cause a board I was working on. At the high level, there were things > like [...] > bugs in my reading of the data sheets every other bug you referred to has a root in this last one. Every spec, at each level of the design flow, might be misinterpreted since there's no process, AFAIK, that can verify the correct interpretation of a requirement. Al [1] An Assessment of Space Shuttle Flight Software Development Processes: http://www.nap.edu/catalog.php?record_id=2222Article: 155977
Dear Hans, > From the examples it looks like a promising piece of technology and I=20 > am always amazed what a single developer can write. first of all, thank you for your kind words. > However, I would strongly suggest you get a few beta testers to go throug= h=20 > the setup and more importantly the usage model of HercuLeS since I think = it=20 > needs some work. I agree. Since mid 2011 I have tried to create a critical mass of beta test= ers however it has proved much more difficult than I thought. Maybe the fre= e version availability (with no licensing requirements) can help towards th= is end. I have also (just) started a collaboration with a high-profile Univ= . lab in Europe (not my native Greece) so HercuLeS can be put under more ex= tensive testing. In Greece we are only maybe 4 people doing HLS; the other 3 didn't show any= particular interest in early-stage testing :) Further, the interest from s= tudents and young researchers/engineers seems to have significantly dropped= due to the ongoing recession (I know this is an excuse). One good thing is that I have more quality time than in the 2010-2012 perio= d, so I am having a good and patient look on issues like application notes,= documentation, introductory materials etc. according to user feedback (e.g= . you have made a remark on the usage model and the setup process). Best regards, Nikolaos Kavvadias Ajax CompilersArticle: 155978
On Wednesday, October 16, 2013 12:17:19 PM UTC-5, Dan Wawa wrote: > Hi, I have designed a microprocessor that works as a USB device that I ca= ll DorQ. I don't know any such company, but a few comments anyway: It looks best to patent this design before offering it to anyone. Your description leaves out a few important details, such as what types of = programs it will speed up that much. Many high-end graphics boards can alr= eady speed up programs by a factor of a few thousand, but only for programs= that have large numbers of sections that can be run in any order or even a= ll at once because they do not affect each other (parallel processing, ofte= n using OpenCL). If this fits your device, offering an OpenCL compiler for= it would help it sell. Also, will it contain a large memory, or must it reach such a memory throug= h the USB connection (which is rather slow for this purpose)? If it can speed up all programs by a factor of several thousand, even those= where all sections must be run one after the other, I'd expect Intel, AMD,= and any other microprocessor makers you can find to be very interested - b= ut also with large budgets to fight legal battles for or against you. The = companies making quantum computers are also likely to be interested, since = they are already working on especially fast computers.Article: 155979
Dan Wawa <danwawa6@gmail.com> wrote: > Hi, I have designed a microprocessor that works as a USB device > that I call DorQ. Its function is to speed up the processing > speed of any computer that it is connected to by a factor of > several thousands of times. Over the years there have been a number of tries at building and selling co-processors for hardware acceleration. Many companies designing and selling such are now gone. Some that are still around are drccomputer and timelogic. It is not so hard to design an add-on coprocessor, but getting useful work from one is somewhat harder. First you have to remember Amdahl's law. Second, you have to make sure that you are not I/O limited. \-- glenArticle: 155980
On Tuesday, December 1, 2009 9:53:18 PM UTC+5, glallenjr wrote: > Currently I am studying the "Circuit Design with VHDL" by Volnei A. > Pedroni. On page 207 the run a simulation but do not provide the test > bench. I would like to run the same simulation but I am not familiar with > how to write a testbench. If possible please provide a testbench to mimic > the simulation shown on page 207. If you are unfamiliar with this book or > the simulation run, I would also appreciate ANY KIND of testbench which > could simulate it's funcionality. Also if there are any errors with the > code, please let me know! Your help is much appreciated! thank you! > > Here is the code we are trying to implement: > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > > entity vending_machine is > Port ( clk, rst : IN STD_LOGIC; > nickel_in, dime_in, quarter_in : IN BOOLEAN; > candy_out, nickel_out, dime_out, quarter_out: OUT STD_LOGIC); > end vending_machine; > > architecture fsm of vending_machine IS > TYPE state IS (st0, st5, st10, st15, st20, st25, st30, st35, st40, st45); > SIGNAL present_state, next_state: STATE; > > begin > PROCESS(rst, clk) > BEGIN > IF(rst='1') THEN > present_state <=st0; > ELSIF(clk' EVENT AND clk ='1') THEN > present_state <= next_state; > END IF; > END PROCESS; > > PROCESS(present_state, nickel_in, dime_in, quarter_in) > BEGIN > CASE present_state IS > WHEN st0 => > candy_out <= '0'; > nickel_out <='0'; > dime_out <= '0'; > IF (nickel_in) THEN next_state <= st5; > ELSIF (dime_in) THEN next_state <= st10; > ELSIF (quarter_in) THEN next_state <= st25; > ELSE next_state <=st0; > END IF; > WHEN st5 => > candy_out <= '0'; > nickel_out <='0'; > dime_out <= '0'; > IF (nickel_in) THEN next_state <= st10; > ELSIF (dime_in) THEN next_state <= st15; > ELSIF (quarter_in) THEN next_state <= st30; > ELSE next_state <=st5; > END IF; > WHEN st10 => > candy_out <= '0'; > nickel_out <='0'; > dime_out <= '0'; > IF (nickel_in) THEN next_state <= st15; > ELSIF (dime_in) THEN next_state <= st20; > ELSIF (quarter_in) THEN next_state <= st35; > ELSE next_state <=st10; > END IF; > WHEN st15 => > candy_out <= '0'; > nickel_out <='0'; > dime_out <= '0'; > IF (nickel_in) THEN next_state <= st20; > ELSIF (dime_in) THEN next_state <= st25; > ELSIF (quarter_in) THEN next_state <= st40; > ELSE next_state <=st15; > END IF; > WHEN st20 => > candy_out <= '0'; > nickel_out <='0'; > dime_out <= '0'; > IF (nickel_in) THEN next_state <= st25; > ELSIF (dime_in) THEN next_state <= st30; > ELSIF (quarter_in) THEN next_state <= st45; > ELSE next_state <=st20; > END IF; > WHEN st25 => > candy_out <= '1'; > nickel_out <='0'; > dime_out <= '0'; > next_state <= st0; > WHEN st30 => > candy_out <= '1'; > nickel_out <='1'; > dime_out <= '0'; > next_state <= st0; > WHEN st35 => > candy_out <= '1'; > nickel_out <='0'; > dime_out <= '1'; > next_state <= st35; > WHEN st45 => > candy_out <= '0'; > nickel_out <='0'; > dime_out <= '1'; > next_state <= st35; > END CASE; > END PROCESS; > > END fsm; > > > > > --------------------------------------- > This message was sent using the comp.arch.fpga web interface on > http://www.FPGARelated.com hello, I have done with this code but if a user inserts 2 nickel or 1 dime and he decided not to take a candy and he want his money back. How could i return his inserted coins without giving him candy. please Reply ASAP thanksArticle: 155981
On Sat, 02 Nov 2013 06:03:56 -0700, fahmeed.zaheer47 wrote: > On Tuesday, December 1, 2009 9:53:18 PM UTC+5, glallenjr wrote: >> Currently I am studying the "Circuit Design with VHDL" by Volnei A. >> Pedroni. On page 207 the run a simulation but do not provide the test >> bench. I would like to run the same simulation but I am not familiar >> with how to write a testbench. If possible please provide a testbench >> to mimic the simulation shown on page 207. If you are unfamiliar with >> this book or the simulation run, I would also appreciate ANY KIND of >> testbench which could simulate it's funcionality. Also if there are any >> errors with the code, please let me know! Your help is much >> appreciated! thank you! >> > > hello, > I have done with this code but if a user inserts 2 nickel or 1 dime and > he decided not to take a candy and he want his money back. How could i > return his inserted coins without giving him candy. please Reply ASAP > thanks I doubt that anyone is here to do your work. Most of us, if we're interested in helping you at all, are here to help you to do your work. Here's what I suggest: * Study the code until you understand it. * Figure out how to add logic to do what you want * Do it * Test it Buckle down, get to work, make it happen. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 155982
On Sat, 02 Nov 2013 09:15:27 +0000, glen herrmannsfeldt wrote: > Dan Wawa <danwawa6@gmail.com> wrote: >> Hi, I have designed a microprocessor that works as a USB device that I >> call DorQ. Its function is to speed up the processing speed of any >> computer that it is connected to by a factor of several thousands of >> times. > > Over the years there have been a number of tries at building and selling > co-processors for hardware acceleration. Many companies designing and > selling such are now gone. > > Some that are still around are drccomputer and timelogic. > > It is not so hard to design an add-on coprocessor, but getting useful > work from one is somewhat harder. First you have to remember Amdahl's > law. Second, you have to make sure that you are not I/O limited. > > \-- glen It sounds like cold fusion to me. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 155983
On 11/2/13, 9:03 AM, fahmeed.zaheer47@gmail.com wrote: > hello, > I have done with this code but if a user inserts 2 nickel or 1 dime and he decided not to take a candy and he want his money back. How could i return his inserted coins without giving him candy. please Reply ASAP > thanks > How is the user to ask for his money back? This is an additional requirement, which will need a change to your Interface Control Document, most likely requiring some additional inputs (to ask for their money back), and maybe some additional states or outputs to avoid abuses. A few big questions that comes up are things like do we want to give him back his OWN coins, to avoid being a slug laundering machine, or become a coin changer. Of course, problems like this are really just homework level tasks, a real machine would need a few more I/Os to handle real world issues like not having change available and select which product.Article: 155984
Tim Wescott <tim@seemywebsite.please> wrote: (snip, I wrote) >> Over the years there have been a number of tries at building and selling >> co-processors for hardware acceleration. Many companies designing and >> selling such are now gone. >> Some that are still around are drccomputer and timelogic. >> It is not so hard to design an add-on coprocessor, but getting useful >> work from one is somewhat harder. First you have to remember Amdahl's >> law. Second, you have to make sure that you are not I/O limited. > It sounds like cold fusion to me. It isn't quite that bad, but it isn't so easy, either. First you have to have a problem that is mostly fixed point add and subtract, maybe some multiplies, too. A favorite one is dynamic programming pattern matching algorithms, such as are used for comparing DNA and protein sequences. That is what timelogic sells, and seems to be still in business. FIR filters might not be so bad, either. Using an FPGA with lots of multiplier blocks would help. If your problems do have a lot of communication between the host and the coprocessor, you need a fast link. DRCcomputer has some that fit in the processor socket of an existing multiprocessor board, such as Opteron. Others are PCIe, which also has a pretty good data transfer rate. That allows for problems with more I/O, but they still have to fit. FPGAs are getting pretty big, though, and for reasonably prices. -- glenArticle: 155985
On Sat, 02 Nov 2013 20:33:42 +0000, glen herrmannsfeldt wrote: > Tim Wescott <tim@seemywebsite.please> wrote: > > (snip, I wrote) > >>> Over the years there have been a number of tries at building and >>> selling co-processors for hardware acceleration. Many companies >>> designing and selling such are now gone. > >>> Some that are still around are drccomputer and timelogic. > >>> It is not so hard to design an add-on coprocessor, but getting useful >>> work from one is somewhat harder. First you have to remember Amdahl's >>> law. Second, you have to make sure that you are not I/O limited. > >> It sounds like cold fusion to me. > > It isn't quite that bad, but it isn't so easy, either. << comments snipped >> I'm not sure what you're reading into what the OP said, but he's promising more than 1e3 improvement in speed just by hooking some gizmo up to a USB port on "any PC in the world", without specifying what its going to do or how. What I read into that is "here be magic, just give me money". -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 155986
Tim Wescott <tim@seemywebsite.really> wrote: >> Tim Wescott <tim@seemywebsite.please> wrote: (snip, I wrote) >>>> It is not so hard to design an add-on coprocessor, but getting useful >>>> work from one is somewhat harder. First you have to remember Amdahl's >>>> law. Second, you have to make sure that you are not I/O limited. >>> It sounds like cold fusion to me. >> It isn't quite that bad, but it isn't so easy, either. > << comments snipped >> > I'm not sure what you're reading into what the OP said, but he's > promising more than 1e3 improvement in speed just by hooking some > gizmo up to a USB port on "any PC in the world", without specifying > what its going to do or how. Rereading the original post, it doesn't mention at all what problem it applies to. More specifically, it doesn't say that it will speed up all problems. How fast can most machines do 8 bit adds these days? It isn't hard to build an array that can do more than 1000 of them in the time another system can do one. If your problems need only 8 bit adds, it might work. You also have to be lucky that the needed I/O rate is low enough. Though USB 3.0 isn't so bad. > What I read into that is "here be magic, just give me money". Need some luck, too. -- glenArticle: 155987
I need a Verilog behavioral model (verilog behavioral code) for: - unsigned 8-bit division The module I have to use is this one: module divider( output reg[7:0] q, output reg[7:0] r, input [7:0] a,b); endmodule where a=b*q+r Is preferable to use SRT, Newton-Raphson or Goldschmidt algorithms to solve it. Can someone help me?Article: 155988
On Sunday, January 17, 2010 6:49:48 PM UTC-6, KJ wrote: > In the end, the main advantage of std_logic is with unknowns. Booleans wi= ll > initialize themselves to 'False', std_logic to 'U'. Proving that your des= ign > does not depend on a lucky initialization value happens when you use > std_logic not booleans. That advantage is reduced considerably when your RTL is full of "if val =3D= '1' then" or similar conditional statements that do not react appropriatel= y to unknown values.=20 If you are willing to express all of your RTL logic as assignments from boo= lean expressions, or include lots of "elsif val =3D 'X' then" statements, t= hen you can realize (in RTL simulation) the benefit of unknown-handling in= std_ulogic-based types. I'd rather have understandable code. I have often used custom is1() or is0() functions (return boolean) that ass= ert a warning, and return false, if passed an unknown value. With them, I c= an use statements like "if is1(my_sig) then" and at least be warned about m= aking a decision based on an uknown value. However, your point about unknown representation and finding initialization= problems is extremely valuable during gate level simulation (post-synthesi= s or post-P&R). Whether you used booleans and integers or not in your RTL, = the gate level model is built around std_ulogic and its aggregates that inc= lude and propagate uknowns appropriately (sometimes too appropriately!). Th= is is where you should test your design's initialization. A quick scan of t= he synthesis tool's utilization summary for any non-reset register primitiv= es also helps a lot. AndyArticle: 155989
Kristo Godari <kristo.godari@gmail.com> wrote: > I need a Verilog behavioral model (verilog behavioral code) for: > - unsigned 8-bit division > The module I have to use is this one: > module divider( > output reg[7:0] q, > output reg[7:0] r, > input [7:0] a,b); > endmodule > where a=b*q+r > Is preferable to use SRT, Newton-Raphson or Goldschmidt algorithms > to solve it. For 8 bits, usually something simpler than those. You don't have a clock, so you can't pipeline it. Remember how you learned to divide in 5th grade? Just like that, but in binary instead of decimal. The ones you mention are most often used for floating point. For one reason, some of those give a rounded quotient, not what you want. -- glenArticle: 155990
Kristo Godari wrote: > I need a Verilog behavioral model (verilog behavioral code) for: > - unsigned 8-bit division > > The module I have to use is this one: > > module divider( > output reg[7:0] q, > output reg[7:0] r, > input [7:0] a,b); > endmodule > > where a=b*q+r > > Is preferable to use SRT, Newton-Raphson or Goldschmidt algorithms > to solve it. > > Can someone help me? This is really a decision based on vailable resources and timing requirements. For example if you have few resources but lots of time then you could do successive subtraction. By the way your module needs a clock to do any sequential algorithm reliably. In an FPGA with a spare multiplier and block RAM I might make a table of inverses in the block RAM and giving the divisor as the address, use that table's output to multiply by the dividend. That would give a new result every clock cycle if necessary. Also you say "behavioral" but I'm guessing you want this module to be synthesizable or else you'd simply use the division operator. -- GaborArticle: 155991
GaborSzakacs <gabor@alacron.com> wrote: > Kristo Godari wrote: >> I need a Verilog behavioral model (verilog behavioral code) for: >> - unsigned 8-bit division (snip) >> Is preferable to use SRT, Newton-Raphson or Goldschmidt algorithms >> to solve it. (snip) > This is really a decision based on vailable resources and timing > requirements. For example if you have few resources but lots of time > then you could do successive subtraction. By the way your module > needs a clock to do any sequential algorithm reliably. Yes, no clock so only combinatorial logic. No matter how long it takes. > In an FPGA with a spare multiplier and block RAM I might make a table > of inverses in the block RAM and giving the divisor as the address, > use that table's output to multiply by the dividend. That would give > a new result every clock cycle if necessary. I forgot about that one. I think you need at least one bit more in the inverse to make it work. Then take the high bits of the product. Many have an 18x18 multiplier, though, so that should be plenty of bits. Might be faster than the series of compare and subtract, too! You can even test all the combinations in software to make sure everything rounds the right way. Then another multiply and subtract to generate the remainder. > Also you say "behavioral" but I'm guessing you want this module to > be synthesizable or else you'd simply use the division operator. Personally, I write mostly structural verilog with continous assignment and module references, except for registers and state machines, but much of behavioral verilog is now synthesizable. I believe they can synthesize from a series of if statements to do conditional subtraction and the appropriate shifts. -- glenArticle: 155992
GaborSzakacs <gabor@alacron.com> wrote: > Kristo Godari wrote: >> I need a Verilog behavioral model (verilog behavioral code) for: >> - unsigned 8-bit division >> The module I have to use is this one: >> module divider( >> output reg[7:0] q, >> output reg[7:0] r, >> input [7:0] a,b); >> endmodule >> where a=b*q+r >> Is preferable to use SRT, Newton-Raphson or Goldschmidt algorithms >> to solve it. >> Can someone help me? (snip) > In an FPGA with a spare multiplier and block RAM I might make a table > of inverses in the block RAM and giving the divisor as the address, > use that table's output to multiply by the dividend. That would give > a new result every clock cycle if necessary. Actually, with a block RAM you can do the whole thing as a look-up table. You have 16 bits input and 16 bits output. But you need a clock for the block RAM on many. For asynchronous RAM you need to use CLB, but it still might be a fine solution, probably faster and less logic than eight levels of compare and subtract. -- glenArticle: 155993
I forgot to say that i can't use '/' or '%'.And i can't change the module structure the module must have 2 inputs and 2 outputs: module divider( output reg[7:0] q, output reg[7:0] r, input [7:0] a,b); /* Code goes here */ endmoduleArticle: 155994
Sorry for my poor english :/
I want to divide unsigned binary integers using non-restoring division!
I have found te algorithm here:
http://stackoverflow.com/questions/12133810/non-restoring-division-algorithm
I have implemented the algorithm on verilog.But for some reason the module does not work correct!
The module code:
I have comented where i think the mistake is!
module divider(
output reg[7:0] q,
output reg[7:0] r,
input [7:0] a, b);
reg[7:0] A;
reg[7:0] B;
reg[7:0] Q;
reg[7:0] M;
reg[7:0] N;
always @(*)
begin
A=8'b00000000;
Q=a;
M=b;
N=8;
while(N > 0)begin
if( A < 0 )
begin
A=A<<1;
Q=Q<<1;
A=A+M;
end
else
begin
//When N=8 A=00000000
A=A<<1;//I have done debugging and here does not shift A with 1 bit,it must but it doesnt why??
Q=Q<<1;
A=A-M;
end
if( A < 0 )
begin
Q[0]=0;
N=N-1;
end
else begin
Q[0]=1;
N=N-1;
end
end
if(A<0)begin
A=A+M;
end
q=Q;
r=A;
end
endmodule
Can anyone find where is my mistake?? Thank you!
Article: 155995Kristo Godari wrote: > Sorry for my poor english :/ > I want to divide unsigned binary integers using non-restoring division! > I have found te algorithm here: > http://stackoverflow.com/questions/12133810/non-restoring-division-algorithm > > I have implemented the algorithm on verilog.But for some reason the module does not work correct! > The module code: > I have comented where i think the mistake is! > module divider( > output reg[7:0] q, > output reg[7:0] r, > input [7:0] a, b); > > reg[7:0] A; > reg[7:0] B; > reg[7:0] Q; > reg[7:0] M; > reg[7:0] N; > > > always @(*) > begin > > A=8'b00000000; > Q=a; > M=b; > N=8; > > while(N > 0)begin > > if( A < 0 ) > begin > A=A<<1; > Q=Q<<1; > A=A+M; > end > else > begin > //When N=8 A=00000000 > A=A<<1;//I have done debugging and here does not shift A with 1 bit,it must but it doesnt why?? > Q=Q<<1; > A=A-M; > end > if( A < 0 ) > begin > Q[0]=0; > N=N-1; > end > else begin > Q[0]=1; > N=N-1; > end > end > if(A<0)begin > A=A+M; > end > q=Q; > r=A; > > end > > endmodule > > Can anyone find where is my mistake?? Thank you! I don't really want to debug this for you, but one thing I noticed is that you're testing for less than zero on A, which is an unsigned 8-bit reg. If you want to test for less than zero, A should be declared as a signed reg. If you really wanted to test for the MSB of A being set, then say "if (A[7])" rather than "if (A < 0)" -- GaborArticle: 155996
Kristo, First of all please don't post multiple times. (Here and comp.lang.verilog). Stay on the same thread too. Now, onto the code. There's some fundamental issues. You're idea is fine - you're coding up basic long division like you do with pen and paper. Just a few tripping points. >module divider( > output reg[7:0] q, > output reg[7:0] r, > input [7:0] a, b); > > reg[7:0] A; > reg[7:0] B; > reg[7:0] Q; > reg[7:0] M; > reg[7:0] N; > > > always @(*) > begin > > A=8'b00000000; > Q=a; > M=b; > N=8; > > while(N > 0)begin I suggest changing this to a 'for' loop. Most synthesizers can handle for loops (if you follow certain rules). While loops can cause more trouble. > > if( A < 0 ) Verilog Reg are default unsigned - and I suggest you stick with the default for now. Knowing this, you'll should see holes in your code. This if clause is always false. It will never execute. > begin > A=A<<1; > Q=Q<<1; > A=A+M; > end > else > begin > //When N=8 A=00000000 > A=A<<1;//I have done debugging and here > Q=Q<<1; > A=A-M; > end > if( A < 0 ) This clause too, will never happen. > begin > Q[0]=0; > N=N-1; > end > else begin > Q[0]=1; > N=N-1; > end > end > if(A<0)begin This one too - never occurs. > A=A+M; > end > q=Q; > r=A; > > end > >endmodule That's a start. I haven't check the math, but you're moving in the right direction. Regards, MarkArticle: 155997
Thank you Mark for your Help :)
I found my mistake!
I was shifting A and Q separately!
My A at the begining is 00000000 when i shift it with a bit it gave me 00000000 and i thought that shift was not working.
Instead i want to shift AQ! Let's assume A=01011 and Q=10010
i want to shift AQ 1 bit to the left so i can have 10111 00100!
I know how to shift AQ by one bit:
AQ={A,Q};
AQ=AQ<<1;
but i dont know how to separate AQ in A and Q after shifting :(
Any idea how to do that?
Thanks Kristo
Article: 155998Hello, Am Montag, 4. November 2013 15:48:28 UTC+1 schrieb Kristo Godari: > I need a Verilog behavioral model (verilog behavioral code) for: > > - unsigned 8-bit division behavioral model means not necessary synthesisable. Easiest is a = b/c. Your teacher don't like you to use this easiest sollution, so he requestst you to learn about additional algorithms and write them down. Forget about pipelining, clock etc. Have a look at the suggested algorithms and translate them in verilog code. bye ThomasArticle: 155999
Kristo Godari wrote:
> Thank you Mark for your Help :)
> I found my mistake!
> I was shifting A and Q separately!
> My A at the begining is 00000000 when i shift it with a bit it gave me 00000000 and i thought that shift was not working.
> Instead i want to shift AQ! Let's assume A=01011 and Q=10010
> i want to shift AQ 1 bit to the left so i can have 10111 00100!
>
> I know how to shift AQ by one bit:
> AQ={A,Q};
> AQ=AQ<<1;
>
> but i dont know how to separate AQ in A and Q after shifting :(
> Any idea how to do that?
> Thanks Kristo
>
>
You mean like:
{A,Q} = {A,Q} << 1;
This shifts both together as a pair. High bit of Q shifts
into the low bit of A. 0 shifts in from the right. High
bit of A drops off the left.
--
Gabor
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