Searching \ for '[EE] Verilog - assignments - this works, but I don' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=verilog+assignments
Search entire site for: 'Verilog - assignments - this works, but I don'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Verilog - assignments - this works, but I don'
2011\05\05@005919 by V G

picon face
Here is my (short and simple) Verilog code to make an array of LEDs blink.
It works.

http://pastebin.com/guQcNkwp

But note that in the module, the LED array is declared as an output reg.
Initially, I tried to use an output wire because I thought a "wire" was
necessary to route a signal to a pin or something. But then I got an error
so I changed it to reg and it works, but I don't know why. I don't really
understand how the register is being routed to the pins of the LEDs.

I don't *really* understand the difference between a wire and reg, and none
of the books I've been reading explain that. Can anyone help

2011\05\05@012606 by Xiaofan Chen

face picon face
On Thu, May 5, 2011 at 12:59 PM, V G <spam_OUTx.solarwind.xTakeThisOuTspamgmail.com> wrote:
> Here is my (short and simple) Verilog code to make an array of LEDs blink..
> It works.
>
> http://pastebin.com/guQcNkwp
>
> But note that in the module, the LED array is declared as an output reg.
> Initially, I tried to use an output wire because I thought a "wire" was
> necessary to route a signal to a pin or something. But then I got an error
> so I changed it to reg and it works, but I don't know why. I don't really
> understand how the register is being routed to the pins of the LEDs.
>
> I don't *really* understand the difference between a wire and reg, and none
> of the books I've been reading explain that. Can anyone help?

I am a beginner as well (and my object is more modest than you --
just to learn some ABCs, not going to do coding). I think the following
URL has a good explanation.
http://www.asic-world.com/tidbits/wire_reg.html



-- Xiaofa

2011\05\05@012651 by Lorenzo Luengo C.

flavicon
face
El 05/05/2011 0:59, V G escribió:
> Here is my (short and simple) Verilog code to make an array of LEDs blink..
> It works.
>
> http://pastebin.com/guQcNkwp
>
> But note that in the module, the LED array is declared as an output reg.
> Initially, I tried to use an output wire because I thought a "wire" was
> necessary to route a signal to a pin or something. But then I got an error
> so I changed it to reg and it works, but I don't know why. I don't really
> understand how the register is being routed to the pins of the LEDs.
>
> I don't *really* understand the difference between a wire and reg, and none
> of the books I've been reading explain that. Can anyone help?

I think the explanation is very intuitive. When you do an assignment (i.e "Led[7:0] <= 8'b11111111;", line 14), you need something to hold the value, somthing an ideal wire cannot, so you need a register (an array of D flip-flops).

If you declared Led as a wire, you could do this like a logic description statement, like "Led [7:0] = count[22];". In this case the register "count" holds the value, and you're tapping this value onto all eight wires in the Led array (my syntax maybe not all correct, you may need to use replication braces {}), and put this outside the "always @" block, because you are describing a connection, not an event or behavior.

It's been nice to see this thread... it made me remember my student times when doing some assignments in FPGAs :D


-- Lorenzo Luengo Contreras
Ingeniero Civil Electrónico
Laboratorio MIDGEO (LF-106)
Facultad de Ciencias Físicas y Matemáticas
Universidad de Concepción
Concepción - Chile
+56-41-2207400
http://midgeo.udec.cl

2011\05\05@023820 by V G

picon face
On Thu, May 5, 2011 at 1:25 AM, Lorenzo Luengo C. <.....lluengoKILLspamspam@spam@dgeo.udec.cl> wrote:
> I think the explanation is very intuitive. When you do an assignment
> (i.e "Led[7:0] <= 8'b11111111;", line 14), you need something to hold
> the value, somthing an ideal wire cannot, so you need a register (an
> array of D flip-flops).
>
> If you declared Led as a wire, you could do this like a logic
> description statement, like "Led [7:0] = count[22];". In this case the
> register "count" holds the value, and you're tapping this value onto all
> eight wires in the Led array (my syntax maybe not all correct, you may
> need to use replication braces {}), and put this outside the "always @"
> block, because you are describing a connection, not an event or behavior.


Thanks. That makes more sense.

> It's been nice to see this thread... it made me remember my student
> times when doing some assignments in FPGAs :D

Oh no, it's not actually an "assignment", I just do this stuff for
fun. I meant the Verilog keyword assignment type of thing

2011\05\05@024030 by V G

picon face
On Thu, May 5, 2011 at 1:26 AM, Xiaofan Chen <xiaofancspamKILLspamgmail.com> wrote:
> I am a beginner as well (and my object is more modest than you --
> just to learn some ABCs, not going to do coding). I think the following
> URL has a good explanation.
> http://www.asic-world.com/tidbits/wire_reg.html

I've been linked to that site many times through various sources, and
read it, but for some reason it still doesn't help me.

I guess I'm the kind of guy who needs to know *exactly* what's going
on at the gate level to really understand it. I'll see how it works in
a simulator or Synplify or something.

It's like, no matter how hard you try, you can't *really* teach C to
someone without teaching them how a computer works at the assembler
level, and how things are pushed onto the stack and so on. Just like
that, I can't just take it as a fact that I need to use a reg and not
a wire, I need to see how the gates are routed and what exactly is
going on

2011\05\05@033304 by Xiaofan Chen

face picon face
On Thu, May 5, 2011 at 2:40 PM, V G <.....x.solarwind.xKILLspamspam.....gmail.com> wrote:
> On Thu, May 5, 2011 at 1:26 AM, Xiaofan Chen <EraseMExiaofancspam_OUTspamTakeThisOuTgmail.com> wrote:
>> I am a beginner as well (and my object is more modest than you --
>> just to learn some ABCs, not going to do coding). I think the following
>> URL has a good explanation.
>> http://www.asic-world.com/tidbits/wire_reg.html
>
> I've been linked to that site many times through various sources, and
> read it, but for some reason it still doesn't help me.

I think one thing is that you need to use reg for sequential logic.

"Something that we need to know about reg is that it can be used for
modeling both combinational and sequential logic. Reg data type can
be driven from initial and always block."

{Quote hidden}

Or maybe you need to have some ABCs of digital electronics
before going into Verilog. But I think you know quite a bit
already, just not formal training, like my programming side
-- I lack formal trainings on C programming even though I learn
a bit by myself and can write some simple programs, but I
do not know very well about programming.

-- Xiaofa

2011\05\05@035329 by V G

picon face
On Thu, May 5, 2011 at 3:33 AM, Xiaofan Chen <xiaofancspamspam_OUTgmail.com> wrote:
> Or maybe you need to have some ABCs of digital electronics
> before going into Verilog. But I think you know quite a bit
> already, just not formal training, like my programming side
> -- I lack formal trainings on C programming even though I learn
> a bit by myself and can write some simple programs, but I
> do not know very well about programming.

Conceptually, I know how transistors are used to make logic gates, and
how those gates can be packaged into an IC. But an FPGA is so much
more complicated than that and is being routed dynamically. The
biggest problem for me is understanding how the compiler treats
different keywords like reg and wire and what they translate to
physically. I can look at static gates and see what they do, that's
not the problem

2011\05\05@043356 by Xiaofan Chen

face picon face
On Thu, May 5, 2011 at 3:53 PM, V G <@spam@x.solarwind.xKILLspamspamgmail.com> wrote:
>
> Conceptually, I know how transistors are used to make logic gates, and
> how those gates can be packaged into an IC. But an FPGA is so much
> more complicated than that and is being routed dynamically. The
> biggest problem for me is understanding how the compiler treats
> different keywords like reg and wire and what they translate to
> physically. I can look at static gates and see what they do, that's
> not the problem.

What about sequential logic, eg, those flip-flops, etc?

What about the other way around, understand the physical
part and then see how they translate to Verilog by the compiler?

-- Xiaofa

2011\05\05@043908 by V G

picon face
On Thu, May 5, 2011 at 4:33 AM, Xiaofan Chen <KILLspamxiaofancKILLspamspamgmail.com> wrote:
> What about sequential logic, eg, those flip-flops, etc?
>
> What about the other way around, understand the physical
> part and then see how they translate to Verilog by the compiler?

I've built a few flip flops as well from transistors and gates. And
how do you translate it to Verilog

2011\05\05@050226 by Michael Watterson

face picon face
On 05/05/2011 08:53, V G wrote:
> Conceptually, I know how transistors are used to make logic gates, and
> how those gates can be packaged into an IC.

That's not important.

What's important is how to to take a problem/application and define the logic, know which parts are sequential or synchronous etc...

The whole point of Verilog and VHDL is to actually hide the implementation details. Tools exist to convert the FPGA design to an ASIC.

When you have entered a design you can without leaving the Xilinx IDE simply click and see the equivalent schematic as if the design was implemented in gates, counters and registers. You can actually also see how it's been mapped to the physical RAM based LUT, and physical registers, Latches, gates and multipliers the FPGA has.

The main difference between "modern" FPGA and original programable logic, is the original parts (Still somewhat in CLPD) in 1980s used array of NANDs and NOR with matrix of wires and "fusable" links.

In college we took same design and 1st did it with whatever logic gates needed. Then we also simply took a truth table of the design and programmed it into an EPROM with inputs on address lines and output as output. If there where states, then D-Type latches connected some output pins to some input addresses.

The FPGA replaces the fusable links with RAM and and the EPROM with RAM. Hence unless the FPGA has onboard Flash, the entire configuration is lost at power off and at power on it must be loaded from a cpu or external Flash Memory.

A processor fetches one or two instructions at a time under program control from Flash. An FPGA loads ALL of the Flash to define the LUT (look up tables) and interconnection wiring multiplexing/definitions (also a form of RAM). Since RAM is very fast and LUT latency is just the RAM access time, FPGA is very fast. An individual logic gate may be fast, but the more complex the logic, the more gates are used and latency increases and also risk of race conditions. The LUT, if big enough has same latency no-matter the logic table and no internal "race" conditions.

Unless you are near the capacity of the FPGA, or near the speed constraints, you don't need to know how it works. That's the whole point of Verilog and VHDL. You do need to know how you would design a solution to system with Logic.

2011\05\05@050713 by Michael Watterson

face picon face
On 05/05/2011 09:38, V G wrote:
> I've built a few flip flops as well from transistors and gates. And
> how do you translate it to Verilog?

That's not important. That's the wrong question.

A Flip flop can be used as a counter or register / latch or generate phase differences
Verilog or VHDL lets you easily specify latches /registers/counters etc. The synthesis may map these to real registers or latches in the FPGA or LUT / RAM or whatever. Most output pins can utilise associated physical latches/flip-flop/registers as this is common need.


2011\05\05@072258 by V G

picon face
On Thu, May 5, 2011 at 5:01 AM, Michael Watterson <RemoveMEmikeTakeThisOuTspamradioway.org> wrote:
> That's not important.
>
> What's important is how to to take a problem/application and define the
> logic, know which parts are sequential or synchronous etc...

I agree, that too is part of the problem.

> The whole point of Verilog and VHDL is to actually hide the
> implementation details. Tools exist to convert the FPGA design to an ASIC..

You could say the same for C. The whole point is to hide the low level
stuff generated by the compiler. All I'm saying is, personally, I need
to know what's being hidden so I can truly understand what's going on.

{Quote hidden}

I guess you don't *need* to know, but I certainly *want* to know

2011\05\05@073906 by Herbert Graf

picon face
On Thu, 2011-05-05 at 00:59 -0400, V G wrote:
> Here is my (short and simple) Verilog code to make an array of LEDs blink..
> It works.
>
> http://pastebin.com/guQcNkwp
>
> But note that in the module, the LED array is declared as an output reg.
> Initially, I tried to use an output wire because I thought a "wire" was
> necessary to route a signal to a pin or something. But then I got an error
> so I changed it to reg and it works, but I don't know why. I don't really
> understand how the register is being routed to the pins of the LEDs.
>
> I don't *really* understand the difference between a wire and reg, and none
> of the books I've been reading explain that. Can anyone help?

A reg is assigned by an always block.
A wire is assigned by either the output of the sub-block, or an assign
statement.
That's all there is to know.

It's a syntax thing.

2011\05\05@074752 by Herbert Graf

picon face
On Thu, 2011-05-05 at 02:40 -0400, V G wrote:
> On Thu, May 5, 2011 at 1:26 AM, Xiaofan Chen <spamBeGonexiaofancspamBeGonespamgmail.com> wrote:
> > I am a beginner as well (and my object is more modest than you --
> > just to learn some ABCs, not going to do coding). I think the following
> > URL has a good explanation.
> > www.asic-world.com/tidbits/wire_reg.html
>
> I've been linked to that site many times through various sources, and
> read it, but for some reason it still doesn't help me.
>
> I guess I'm the kind of guy who needs to know *exactly* what's going
> on at the gate level to really understand it. I'll see how it works in
> a simulator or Synplify or something.

You are writing in HDL. HDL is stands for "hardware description
language". You AREN'T WRITING GATES, you're writing a description of
hardware that a tool (the synthesizer) will analyze and infer logic to
do what you're asking.

Whether you use a wire or reg depends on what construct you use (simply:
wires are connect to the outputs of instantiated modules, or assigned to
by an assign statement, regs are written to by an always block).

Here's something to consider, have a look at these assign statements and
assume your compiling for an FPGA:

input in1, in2;
output out;
wire net1;
assign net1 = !in1;
assign out = net1 & in2;

You might assume that the synthesizer will do the following:

in1 -> (not) -> net1 -> (
                       (and) -> out
in2 ------------------> (

And you might assume that net1 is a wire in your FPGA.

You'd be wrong.
If you open up FPGA Editor/Planahead you'd discover that Net1 doesn't
exist in your FPGA. The reason is the synthesizer will combine the two
assign statements into one LUT element. Even though you declared net1 as
a wire, it won't exist as a wire in the FPGA.

Remember, you are guiding the tool with your HDL, you're not telling the
tool which gates to use.

TTYL

2011\05\05@074908 by Herbert Graf

picon face
On Thu, 2011-05-05 at 15:33 +0800, Xiaofan Chen wrote:
> On Thu, May 5, 2011 at 2:40 PM, V G <TakeThisOuTx.solarwind.xEraseMEspamspam_OUTgmail.com> wrote:
> > On Thu, May 5, 2011 at 1:26 AM, Xiaofan Chen <RemoveMExiaofancspamTakeThisOuTgmail.com> wrote:
> >> I am a beginner as well (and my object is more modest than you --
> >> just to learn some ABCs, not going to do coding). I think the following
> >> URL has a good explanation.
> >> www.asic-world.com/tidbits/wire_reg.html
> >
> > I've been linked to that site many times through various sources, and
> > read it, but for some reason it still doesn't help me.
>
> I think one thing is that you need to use reg for sequential logic.
>
> "Something that we need to know about reg is that it can be used for
> modeling both combinational and sequential logic. Reg data type can
> be driven from initial and always block."

initial blocks are not synthesizer and should NOT be used for FPGA
designs, except for test bench blocks only used during simulation.

If you need something initialized, use reset, that's what it's for.

TTYL

2011\05\05@075648 by V G

picon face
On Thu, May 5, 2011 at 7:49 AM, Herbert Graf <hkgrafEraseMEspam.....gmail.com> wrote:
> initial blocks are not synthesizer and should NOT be used for FPGA
> designs, except for test bench blocks only used during simulation.
>
> If you need something initialized, use reset, that's what it's for.

Hm. I'll keep that in mind

2011\05\05@085730 by Michael Watterson

face picon face
On 05/05/2011 12:47, Herbert Graf wrote:
{Quote hidden}

Good clear post

Vote ++

2011\05\05@095351 by Martin Darwin

flavicon
face


On May 5, 2011, at 7:22 AM, V G <RemoveMEx.solarwind.xEraseMEspamEraseMEgmail.com> wrote:

>>
> You could say the same for C. The whole point is to hide the low level
> stuff generated by the compiler. All I'm saying is, personally, I need
> to know what's being hidden so I can truly understand what's going on.

You will need to do lots of reading & experimenting then.  
With HDL you have to put trust in the synthesis tools to give the right output. Understanding all the ways it optimizes your logic would be difficult. So what I write in hdl might look very weird in gates because of all the optimizations. That said, sometimes the tools optimize in ways you don't want so you have to constrain them.  Post-synthesis simulation & verification is required to make sure the tools didn't make a mess.....i have this issue right now!!! Lots of work to figure out the problem on large designs.

2011\05\05@105433 by Michael Watterson

face picon face
On 05/05/2011 12:22, V G wrote:
> You could say the same for C. The whole point is to hide the low level
> stuff generated by the compiler. All I'm saying is, personally, I need
> to know what's being hidden so I can truly understand what's going on.

no you don't. Even on C on any CPU big enough to have a "mainstream" OS, 99% of expertise is not even knowing C syntax, but C libraries. Unless you are writing a device driver you don't want to know how it's implemented. Even then what you "need to know" of what is "hidden" by compiler is very little.

You need to learn what you are doing.  Herbert appears to be expert on this stuff.

What is your Goal?
Unless you are doing designs at limit of the capacity of speed/"gate utilisation" you don't need to know what is inside unless you are designing FPGA.
Even if you are going to only do Verilog you should spend 2 days to  a week looking at VHDL.
Unless you have specific goals or project that needs FPGA you will find it hard to keep up momentum and focus on the real issues to learn.

I have done even device driver stuff on ARM and x86 Linux. ARM is RISC and could be SoC almost all the I/O of a laptop with maybe less than 200,000 transistor core. Intel x86 might use ten chips or more for same I/O and separate CISC CPU with over Billion transistors (x50 more). The same C device driver code compiles for both for the PCMCIA modem.

If you doing "real time" timing on CPU in software, you may look inside the x86 when it doesn't work, decide it's a horror and make a plug in USB dongle that uses an 18F  PIC instead :)

2011\05\05@110802 by V G

picon face
On Thu, May 5, 2011 at 10:54 AM, Michael Watterson <RemoveMEmikespam_OUTspamKILLspamradioway.org> wrote:
> no you don't. Even on C on any CPU big enough to have a "mainstream" OS,
> 99% of expertise is not even knowing C syntax, but C libraries. Unless
> you are writing a device driver you don't want to know how it's
> implemented. Even then what you "need to know" of what is "hidden" by
> compiler is very little.

I define necessity here in terms of my personal requirement to understand.

Maybe it's just me, but I had a hard time explaining the concept of
"returning" a value in C to a classmate who doesn't know what CPU
registers and stacks are.





In any case, after fiddling around with Verilog for a while, I finally
got around to making something cool: http://pastebin.com/GLTueVuE

It just counts the clock pulses in a register and displays them on an
array of LEDs. At the same time, it drives a multiplexed 4-digit
7-segment display and displays any value you like. All written nicely
and with modules instantiated and stuff.

Finally getting the hang of this thing. Hardest thing so far was
deciding whether identifiers should be registers or wires

2011\05\05@113136 by Michael Watterson

face picon face
On 05/05/2011 16:02, V G wrote:
> It just counts the clock pulses in a register and displays them on an
> array of LEDs. At the same time, it drives a multiplexed 4-digit
> 7-segment display and displays any value you like. All written nicely
> and with modules instantiated and stuff.

I just made one using PIC yesterday :)

See  http://www.techtir.ie/node/1003699  and http://www.techtir.ie/node/1003702


>  I define necessity here in terms of my personal requirement to understand.
>

Design an FPGA then. And write a tool to synthesise the configuration from Verilog


>  Maybe it's just me, but I had a hard time explaining the concept of
>  "returning" a value in C to a classmate who doesn't know what CPU
>  registers and stacks are.

Well, normally people learn what a stack orientated computer is as part of learning to program. If you have learnt to program then C just looks like a smart macro assembler and it's a matter of learning the syntax and what libraries are commonly used.  Learning C is completely separate to learning to Program. If you know "programming" then you can pick up any language in a few days, it's just syntax.

Some courses even use a simulation of a simple CPU and associated simple assembler. I guess the PIC isn't appropriate for that as the original 16F isn't really stack orientated, only has stack for  Interrupt return address.  In that respect C on 16F is an achievement  as it  pass parameters and have Functions. BASIC and Forth quite often use virtual machine or "p-code" type approaches, as does JAL. This lets you simulate a stack without the need for the CPU to have a real one.

Using Verilog and VHDL  is not of course Programming

2011\05\05@120139 by Herbert Graf

picon face
On Thu, 2011-05-05 at 09:54 -0400, Martin Darwin wrote:
>
> On May 5, 2011, at 7:22 AM, V G <RemoveMEx.solarwind.xTakeThisOuTspamspamgmail.com> wrote:
>
> >>
> > You could say the same for C. The whole point is to hide the low level
> > stuff generated by the compiler. All I'm saying is, personally, I need
> > to know what's being hidden so I can truly understand what's going on.
>
> You will need to do lots of reading & experimenting then.  
>
> With HDL you have to put trust in the synthesis tools to give the right output. Understanding all the ways it optimizes your logic would be difficult. So what I write in hdl might look very weird in gates because of all the optimizations. That said, sometimes the tools optimize in ways you don't want so you have to constrain them.  Post-synthesis simulation & verification is required to make sure the tools didn't make a mess.....i have this issue right now!!! Lots of work to figure out the problem on large designs.

Very true, in fact a common optimization that catches ALOT of users is
state machines.

State machines are rarely encoded the way the code states. The reason is
there are various ways to encode a state machine that increases speed,
reliability and area (grey coding, one hot, etc.).

This USUALLY isn't a problem. But say you're working on a design that
you can't simulate, for whatever reason (happens often enough on big
designs).

Those that use either explicit (compiled in) probes, or those that use a
post synthesis probing tool (such as chipscope) will bump into the fact
that the STATE variable will likely have ZERO relation to the code in
question.

For Xilinx users you can look at the report produced by the synthesis
tool to determine what remapping was done. But if you forget this,
things can get very confusing.

FPGAs sure can be fun!!

TTYL

2011\05\06@001727 by William \Chops\ Westfield

face picon face

>> so I can truly understand what's going on.

You might find it helpful to look at some simpler PLD-like devices.
If you go to the datasheet for a PAL16L8 or similar, it is very
explicit about what the internal logic looks like, (ORs of internal
ANDS) and where your "firmware" actually causes connections.

A PAL16R8 is similar but adds flipflops at the outputs.

A GAL16V8 replaces the flipflops and OR gates with a logic block
that can do either one, plus some other things.

A CPLD just keeps adding bits (internal registers and paths,
additional gates that are programmable, etc), and so on...

FPGAs are ... actually I'm not too familiar with how FPGAs are
different.  Presumably you start replicating PLD functions with
programmable interconnects, making it basically similar (except
the use of LUTs allows arbitrary logic functions of N inputs
rather than the more limited OR of ANDs, and so on.

BillW

2011\05\06@042832 by alan.b.pearce

face picon face
> You could say the same for C. The whole point is to hide the low level
> stuff generated by the compiler. All I'm saying is, personally, I need
> to know what's being hidden so I can truly understand what's going on.

That is where not playing with an FPGA at this stage is what you should be doing, and getting a feel for 'general' electronics and programming first. In some ways I feel you are attempting to put the cart before the horse.

Think in terms of pulling on the door handle of a car, to open the door. You don't need to understand how the this lever pulls that arm against this spring to rotate the other gizmo to unlatch the door - you have faith in the higher level workings that pulling the handle unlatches the door. You should get to a point where you have faith in the tools you are using to treat them as the same sort of black box producing the end result you want. You need some degree of knowledge about the tool (you pull on the handle, not rotate it) to make the tool work, but you only need the inner understanding when things go wrong. But often you don't need a lot of understanding (squirt some WD40 into the lock to unjam it) to sort out a problem, or some advice from others (such as you have been getting here on this thread) and go from there.
-- Scanned by iCritical.

2011\05\06@082856 by Olin Lathrop

face picon face
Michael Watterson wrote:
> I guess the PIC isn't appropriate for that as the
> original 16F isn't really stack orientated, only has stack for
> Interrupt return address.

No, the stack is used for all return addresses, whether they be as a result
of a interrupt or a explicit call.

> BASIC and Forth quite often use virtual
> machine or "p-code" type approaches, as does JAL.

Really?  I have heard of JAL being referred to as a "compiler" many times,
and it supposedly uses GCC on Unix systems.

> This lets you simulate
> a stack without the need for the CPU to have a real one.

That's one way, but you don't need p-code to have a stack on a PIC 16.  My
PIC development environment, for example, comes with software data stack
capability on a PIC 16.  Bytes can be pushed and popped in the assembler
code at any time, and the stack is used by default on subroutine entry and
exit to save and restore the general registers trashed by a subroutine.



********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\05\06@085424 by Michael Watterson

face picon face
On 06/05/2011 13:29, Olin Lathrop wrote:
> Really?  I have heard of JAL being referred to as a "compiler" many times,
> and it supposedly uses GCC on Unix systems.
The JAL source is compiled to p-Code
The p-code is translated or compiled  to PIC Assembler at "Compile time" There is no run time "engine".

On 16F87x the real HW stack usage does increase from 50% to 75% if a Procedure call is done in an ISR (JAL, some C compilers for PIC don't allow Function call at all in an ISR) . But the Stack isn't being used for Parameters like on Z80 or x86 implementations of C.


>
>No, the stack is used for all return addresses, whether they be as a result
>of a interrupt or a explicit call.
>
That's an implementation dependency.  It's possible to implement a SW stack for even recursion / nested calls etc, threads etc and only use the HW stack for ISR return..

The older PIC certainly can't use the HW stack to pass paramenters or return them. Some have very limited HW stack.


There is of course a large grey area of  High Level Languages that have some compiling and mostly run time Interpretor (runtime per block compile or P-code virtual machine) to systems with "some" run time support and interpretation to C, C++ and Modula-2 systems with zero run time system and just 100% compile to native.

2011\05\06@090050 by Michael Watterson

face picon face
On 06/05/2011 13:29, Olin Lathrop wrote:
> Really?  I have heard of JAL being referred to as a "compiler" many times,
> and it supposedly uses GCC on Unix systems.
>

There is no GCC of JAL. There is an embryonic JAL to C translator (The idea being to use this for non 10/12/16/18F cpus). IMO a stupid idea. Be better to take JAL's intermediate p-Code and do stuff with it as it hardly changes ever compared with the JAL Language. A compiler from JAL's p-code to ARM etc is a better idea.

JAL compiler does run on Linux, Mac OS and Windows as the source is available and it's in C. Compilers are easy enough to port to different hosts if the target code is unchanged (PIC 10/12/16/18 families in this case) as there no I/O other than file.

2011\05\06@090957 by Olin Lathrop

face picon face
Michael Watterson wrote:
>  >No, the stack is used for all return addresses, whether they be as a
> result
>  >of a interrupt or a explicit call.
>
> That's an implementation dependency.

We were talking about the PIC 16 hardware, so this is not something the
application gets to decide.  Of course you can implement your own call and
return functions, but that then has nothing to do with running on a PIC 16
anymore.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\05\06@091156 by Olin Lathrop

face picon face
Michael Watterson wrote:
> There is no GCC of JAL.

According to http://jal.sourceforge.net, "JAL will compile natively on Linux
using gcc".


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2011\05\06@104753 by alan.b.pearce

face picon face
>
> Michael Watterson wrote:
> > There is no GCC of JAL.
>
> According to http://jal.sourceforge.net, "JAL will compile natively on Linux
> using gcc".
>
So it is using GCC to compile the C source for the JAL compiler ???


-- Scanned by iCritical.

2011\05\06@110707 by Michael Watterson

face picon face
On 06/05/2011 15:47, EraseMEalan.b.pearcespamspamspamBeGonestfc.ac.uk wrote:
>> Michael Watterson wrote:
>>> >  >  There is no GCC of JAL.
>> >  
>> >  According tohttp://jal.sourceforge.net, "JAL will compile natively on Linux
>> >  using gcc".
>> >  
> So it is using GCC to compile the C source for the JAL compiler ???
>
>

Yes, just use GCC to build the  "JAL compiler" for Linux (2.4n is latest), not use GCC to compile JAL language at all.

But it's probably available already cooked as a binary as many are using JAL on Linux.

2011\05\06@111822 by William \Chops\ Westfield

face picon face

On May 6, 2011, at 6:12 AM, Olin Lathrop wrote:

>> There is no GCC of JAL.
>
> According to http://jal.sourceforge.net, "JAL will compile natively  
> on Linux
> using gcc".


They mean:  "The JAL compiler may be built on Linux using gcc."
gcc (aside from runtime libraries) is not involved in the compilation
of JAL code to PIC binaries...

BillW

2011\05\06@115017 by Herbert Graf

picon face
On Thu, 2011-05-05 at 21:17 -0700, William "Chops" Westfield wrote:
{Quote hidden}

FPGAs actually simplify things on the hardware side (depending how you
look at things of course).

The simplest FPGAs tend to be arrays of "slices" (the term differs
depending on vendor). Each slice usually contains one LUT (the number of
inputs that LUT has depends on the FPGA) and a Flop/latch. That's pretty
much it.

Each slice is connected to a ton of interconnect that allows it to
connect to a bunch of other LUTs and IO pads.

Pretty much all FPGAs have dedicated clock hardware, consisting of fast
paths to the LUT flops and IO pads, and other clock related stuff like
DLLs/PLLs, clock dividers, muxs, clock gaters (although modern tools
will avoid clock gating and instead use flops with enables, gating a
clock in an FPGA is generally bad unless you really know what you're
getting in to), etc.

As FPGAs get more complex they start adding blocks. Modern FPGAs have
SRAM (both as self contained blocks and also distributed in slices), DSP
blocks (for doing math), CPU cores, etc.

On top of that though you have all the hardware related to configuring
the FPGA, usually meaning as a minimum a JTAG chain and configuration
SRAM. Most parts have faster interfaces for configuration (for
connecting to PROMs).

TTYL

2011\05\09@161347 by Gerhard Fiedler

picon face
V G wrote:

>> The whole point of Verilog and VHDL is to actually hide the
>> implementation details. Tools exist to convert the FPGA design to an
>> ASIC.
>
> You could say the same for C. The whole point is to hide the low
> level stuff generated by the compiler. All I'm saying is, personally,
> I need to know what's being hidden so I can truly understand what's
> going on.

You may be able to see this the other way 'round. I just ported a rather
complex C++ application from Linux for x86 Intel type processors to
Linux for IBM System z processors. I do have some understanding of how a
modern x86 type processor works, but really understanding it is simply
out of my scope -- that's a whole professional life of its own. Much
less do I fully understand an IBM System z processor.

However, what made it possible for me to port is that I understand C++,
particularly here constructs that are commonly used but not actually
guaranteed by the language standard. When you understand the language,
there is a whole lot you can do with this -- it is a system of its own.
In this case, this enabled me to find whatever was there in the code
that assumed running on an Intel processor, doing things that were not
guaranteed by the language. (Endian-dependent code is one of these.)

What you may want are examples of what a language does with whatever you
feed it, so that you get a better understanding of the language
constructs. But with a language of any complexity, you should not forget
that these are only examples -- what a compiler does in a specific case
is rarely deterministic in the sense that you can know it before you see
what it actually did. C is a very simple language, and it already has
this characteristic with decent compilers. I'm quite sure that the
optimizers in decent Verilog compilers are much more complex, and rarely
allow you to know what a certain line of code does -- notwithstanding
the fact that translating a few versions of a simple program, with small
changes from one to the other, into a schematic probably helps you
understand the language better.
Gerhar

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...