0
\$\begingroup\$

I'm interested in Verilog, but I have a question. I tried to implement modulo without using '%` operator. So I made it this way:

while (c>=d) loop
    c <= c-d;
end loop;

Is it right? Any suggestions on where I made the mistake? This is a modulo.vhd [[sunkist]()[1] [sunkist]()[2] This is a tb_modulo.vhd [sunkist]()[3]

\$\endgroup\$
4
  • 1
    \$\begingroup\$ Well, unless you count the number of iterations, you don't actually get a quotient. All you're left with is the remainder. Also, this kind of indefinite loop cannot be synthesized (turned into hardware). \$\endgroup\$
    – Dave Tweed
    Jun 1 '17 at 13:05
  • \$\begingroup\$ How big are your numbers? If they are only a few bits (e.g. 8bit) you can do division using a RAM lookup table. \$\endgroup\$ Jun 1 '17 at 14:40
  • \$\begingroup\$ Its maximum bit is 10bit! Would you modify my coding? I'll add my all verilog code. \$\endgroup\$ Jun 1 '17 at 21:35
  • 1
    \$\begingroup\$ Umm, your question said verilog but then you went and posted a bunch of VHDL, knowing what language you are working in is a good first step towards succesful programming. \$\endgroup\$ Jun 1 '17 at 22:24
6
\$\begingroup\$

There are a few problems here.

The first and most immediate problem is you are using a non-blocking assignment. So the assignment to c won't happen until the end of the current time delta. This means that you have an infinite loop.

Assuming we fix that however there are still several major issues with the code.

  1. You aren't actually counting the number of loop iterations. So you only get the remainder not the quotient.
  2. If c is zero you have an infinite loop.
  3. To synthesize a loop the synthesis tool must be able to statically determine the maximum number of iterations. With more complex loops it may fail to do this even if a human can see that the iterations are bounded.
  4. Even if you fix the code to bound the number of iterations in a way the synthesis tool can understand the code will explode into a massive pile of combinatorial logic. Errors like "can't fit design in device" or "timing requirements were not met" are quite likely.
  5. Repeated subtraction is in general a pretty terrible division algorithm.

In summary it's time to go back to the drawing board.


Some hints on how to tackle something like this.

First specify your requirements, how quickly do you need a result? how often? how big are your inputs and outputs?

Second choose an algorithm, for a beginner I would suggest binary long division, it's not the best algorithm but it's easy to understand and much less resource-intensive than repeated subtraction.

Third choose an implementation strategy, there are basically three to choose from.

  1. Combinatorial, no flip-flops within the divider (optionally you may have flip-flops at the inputs and outputs), simple to get your head around and means you get a result quickly in terms of clock cycles but uses a lot of logic and is likely to limit your clock speed.
  2. State-machine based. A state machine steps through a series of steps re-using the same logic for different steps of the process. This will give a compact design that can work at high clockspeeds but you will not be able to do a division on every clock and will have to wait for the results.
  3. Pipelined. The process is split into major steps with flip-flops between them. Gets you high throughput at high clock speeds but uses a lot of logic, lining up the timings is a PITA and you still have to wait for your first result.
\$\endgroup\$
1
  • \$\begingroup\$ Oh I'm sorry... I was confused... I actually want to code modulo without using "%". Would you modify my coding? I'm sorry... \$\endgroup\$ Jun 1 '17 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.