EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

"rising_edge(clk)" and delay

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - VHDL Language - "rising_edge(clk)" and delay

Goto page Previous  1, 2

rickman
Guest

Sun Jun 12, 2016 1:24 am   



On 6/11/2016 2:35 PM, kristoff wrote:
Quote:
Hi Cecil,


On 11-06-16 17:25, Cecil Bayona wrote:

I must say that learning FPGAs just for books seams to be not very easy.
There seams to be all kind of "need to knows" that are usually not
covered in the books, so thank you, but to you and to Rick, for your
replies.

As a newbie I also agree, most books, and I have several books, they are
either are too vague design books, or most jump right into the code but
leave out a lot of information, they give a lot of details but leave out
the overall picture.


For me, the problem is that I really never learned much about digital
logic, I studied electronics some 25 years ago when we already had
microcontrollers (my thesis was with a 8051).

We did learn about basic digital logic (and, or, not, ...), we never
really learned how to solve a problem with it.

If you had an issue that involved some kind of "logic" more complex then
a couple of 74xx ICs and combinational logic, you simply used a
microcontroller and solved it that way.

We never really learned about thinks like sequential logic, timing,
clocks, etc, ... or how to solve a technical issue with digital logic
components; and ... this is what I need now.

Certain concepts used in "programming" (e.g. the idea of a statemachine)
are also usefull in sequencial logic, but that's about it. The rest is
-for me- all quite new.


There is one important concept that you will need when you are
simulating VHDL circuits, that is the delta delay. The delta delay is
used to deal with the problem of simulating concurrent logic.

When a signal changes, any process (which includes each concurrent logic
statement as they are also processes) that depends on that signal runs
simultaneously. However, in a simulator "simultaneously" is emulated by
evaluating each process one at a time. If the outputs from one process
are used by another the results will depend on which process is run first!

proc_A: process (clk) begin
if rising_edge(clk) then
A <= B + C;
end if;
end process proc_A;

proc_D: process (clk) begin
if rising_edge(clk) then
D <= A + C;
end if;
end process proc_D;

When clk changes both assignments are evaluated. If proc_A runs first,
it becomes A' <= B + C', where the ' indicates the new version of each
signal. proc_D will be evaluated next as D' <= A' + C' or <= B + C' +
C'; So far, so good.

But what if proc_D runs first? It will assign D' <= A + C' or <= B + C
+ C'; clearly a different result.

The way to get around this is to use delta delays for all signal
assignments. A delta delay can be thought of as smaller than the time
resolution of the simulation. So it won't show up as a time delay
anywhere, but it affects the ordering of all processes in the system.

In the above example when clk rises at time t=0 it triggers both
processes to run. However, the assignments will be queued for time
t=0+d where d represents a delta delay. So once all the processes have
run at time t=0, the signals will be updated to their new values at
t=0+d which will give the result shown in the second case above.

BTW, Verilog doesn't use delta delays, so I don't know how they get
consistent and accurate results from their simulations.

I don't know if you have any confusion about this, but I am laid up
after a hip surgery and have nothing better to do... lol


Quote:
I assume one will just have to work with full working examples and read
through and them do small hardware projects using the knowledge and
code from prior working projects, and see how things turn out.
At some point I expect that things will start making sense and one can
start making small hardware projects without copy and paste, but that
point is nowhere here for now.

I started looking around for websites that offer simple exercises to
learn this.

Perhaps we can share some ideas on exercises we come up ourselfs.


At this time, I have two things I want to rey out:
- first, an I/O extender with SPI.

The SPI-protocol is not that complex and looks to me like a nice example
of "clocked" sequencial logic.


SPI is very simple indeed, but in general well thought out. The labels
clearly indicate the direction of signal flow and the clocking avoids
race conditions if used properly. The down side is that it is a bit
more flexible than needed so it can be a bit tricky to set up.


Quote:
I think it might be doable, to create a VHDL design/circuit that allow
you to set or clear output pins on a FPGA/CPLD, based on commands
issued via SPI (from a microcontroller).


When you say "commands", usually the I/O bits are set/cleared directly
from the data shifted through the SPI port. There is normally the shift
register that receives the serial data (and provides for shifting data
out) which is transferred to the output register when the select line is
deasserted.


Quote:
- a lot more difficult (perhaps as a "final exercise") is this:
https://www.youtube.com/watch?v=35zLnS3fXeA

This is a very simple broadboard based 8-bit processor (which seams to
be the "SAP" architecture used in quite a number of text-book on
microprocessor architecture) completely implemented in 74xx ICs.


That might be an ok project, but when it is done, what do you have?
Just an exercise. You might want to design some pieces that will be
useful to you in the future.


Quote:
I currently how no idea how easy or difficult this will be, but perhaps
duplicating this in VHDL would be the ultimate "final test" exercise :-)




Do you -or somebody else- have ideas for exercises that might be
interesting to learn how to solve actual real problems with logic?


A reasonably simple example would be a basic, fixed size UART, say 8
bits, no parity, one stop bit. Design the transmitter and receiver
separately and test by connecting them together and shipping characters
across. Equally important is the test bench used to test your design.
You need to learn how to construct simple and yet powerful test benches
to stimulate your designs and verify the output. It is not uncommon for
the test bench to be as complex as the design you are testing, but
hopefully can be done more simply. In this case you can use the UART
transmitter to test the UART receiver and vice versa. The test bench
only needs to stimulate the parallel input/output and the control
strobes. It also does not need to be synthesizable and so can be
written more like a standard sequential program.

Once you have that working correctly, you can add programmable controls
for the word size, parity and stop bits. That gets a bit more complex
and your test bench will be more complex as well.

Both of these exercises will result in useful code. Often you can use a
simple, fixed size UART in your designs. Other times you will need a
programmable UART so it can be configured by software or changed for
different modes of operation.

Just a thought.

--

Rick C

rickman
Guest

Sun Jun 12, 2016 2:32 am   



On 6/11/2016 4:13 PM, KJ wrote:
Quote:
On Saturday, June 11, 2016 at 3:24:43 PM UTC-4, rickman wrote:

There is one important concept that you will need when you are
simulating VHDL circuits, that is the delta delay. The delta delay is
used to deal with the problem of simulating concurrent logic.

When a signal changes, any process (which includes each concurrent logic
statement as they are also processes) that depends on that signal runs
simultaneously. However, in a simulator "simultaneously" is emulated by
evaluating each process one at a time. If the outputs from one process
are used by another the results will depend on which process is run first!


The part about "the results will depend on which process is run first!" is not correct. At least not with VHDL.

proc_A: process (clk) begin
if rising_edge(clk) then
A <= B + C;
end if;
end process proc_A;

proc_D: process (clk) begin
if rising_edge(clk) then
D <= A + C;
end if;
end process proc_D;

When clk changes both assignments are evaluated. If proc_A runs first,
it becomes A' <= B + C', where the ' indicates the new version of each
signal. proc_D will be evaluated next as D' <= A' + C' or <= B + C' +
C'; So far, so good.

But what if proc_D runs first? It will assign D' <= A + C' or <= B + C
+ C'; clearly a different result.


This is wrong. Both processes are sensitive only to changes in the signal clk. Because of the 'if rising_edge(clk)', the statements that assign to 'A' and 'D' will only get executed on the rising edge of clk. Neither signal will get updated until all processes that were run on that particular cycle have been executed and suspend.

Using any compliant VHDL simulator, there will be no differences in the values of 'A' and 'D' based upon which process gets executed first.

The way to get around this is to use delta delays for all signal
assignments. A delta delay can be thought of as smaller than the time
resolution of the simulation. So it won't show up as a time delay
anywhere, but it affects the ordering of all processes in the system.


This is what the simulator does, not the user. Is that what you're trying to describe??

In the above example when clk rises at time t=0 it triggers both
processes to run. However, the assignments will be queued for time
t=0+d where d represents a delta delay. So once all the processes have
run at time t=0, the signals will be updated to their new values at
t=0+d which will give the result shown in the second case above.


This is correct...but directly contradicts what you had said earlier about the values depending on the order of execution of the processes which is not correct for VHDL. I'm guessing that you were talking about some hypothetical language model that looks like VHDL (since that's what your two example processes look like), but in fact really is not (since it updates the signals at the end of each process, which is not what the VHDL LRM specifies).


I don't know if you have any confusion about this, but I am laid up
after a hip surgery and have nothing better to do... lol


Maybe you took too many pills before you posted (kidding, hope you get well soon).


As I said in the opening paragraph, I was trying to explain the concept
of delta delay. Now go back and read it again. I doubt Kristoff has
learned about the delta delay yet and might not understand how processes
interact if you don't have unit delays.

--

Rick C

rickman
Guest

Sun Jun 12, 2016 2:45 am   



To clear up any confusion created if you already have some knowledge of
delta delays in VHDL, read my comments below.

On 6/11/2016 3:24 PM, rickman wrote:
Quote:
On 6/11/2016 2:35 PM, kristoff wrote:
Hi Cecil,


On 11-06-16 17:25, Cecil Bayona wrote:

I must say that learning FPGAs just for books seams to be not very
easy.
There seams to be all kind of "need to knows" that are usually not
covered in the books, so thank you, but to you and to Rick, for your
replies.

As a newbie I also agree, most books, and I have several books, they are
either are too vague design books, or most jump right into the code but
leave out a lot of information, they give a lot of details but leave out
the overall picture.


For me, the problem is that I really never learned much about digital
logic, I studied electronics some 25 years ago when we already had
microcontrollers (my thesis was with a 8051).

We did learn about basic digital logic (and, or, not, ...), we never
really learned how to solve a problem with it.

If you had an issue that involved some kind of "logic" more complex then
a couple of 74xx ICs and combinational logic, you simply used a
microcontroller and solved it that way.

We never really learned about thinks like sequential logic, timing,
clocks, etc, ... or how to solve a technical issue with digital logic
components; and ... this is what I need now.

Certain concepts used in "programming" (e.g. the idea of a statemachine)
are also usefull in sequencial logic, but that's about it. The rest is
-for me- all quite new.

There is one important concept that you will need when you are
simulating VHDL circuits, that is the delta delay. The delta delay is
used to deal with the problem of simulating concurrent logic.


If delta delays were *not* used...

Quote:
When a signal changes, any process (which includes each concurrent logic
statement as they are also processes) that depends on that signal runs
simultaneously. However, in a simulator "simultaneously" is emulated by
evaluating each process one at a time. If the outputs from one process
are used by another the results will depend on which process is run first!

proc_A: process (clk) begin
if rising_edge(clk) then
A <= B + C;
end if;
end process proc_A;

proc_D: process (clk) begin
if rising_edge(clk) then
D <= A + C;
end if;
end process proc_D;


Assume C has changed to C' prior to the rising clock edge.

Quote:
When clk changes both assignments are evaluated. If proc_A runs first,
it becomes A' <= B + C', where the ' indicates the new version of each
signal. proc_D will be evaluated next as D' <= A' + C' or <= B + C' +
C'; So far, so good.

But what if proc_D runs first? It will assign D' <= A + C' or <= B + C
+ C'; clearly a different result.


But VHDL does always make use of delta delays when making signal
assignments... so...

Quote:
The way to get around this is to use delta delays for all signal
assignments. A delta delay can be thought of as smaller than the time
resolution of the simulation. So it won't show up as a time delay
anywhere, but it affects the ordering of all processes in the system.

In the above example when clk rises at time t=0 it triggers both
processes to run. However, the assignments will be queued for time
t=0+d where d represents a delta delay. So once all the processes have
run at time t=0, the signals will be updated to their new values at
t=0+d which will give the result shown in the second case above.

BTW, Verilog doesn't use delta delays, so I don't know how they get
consistent and accurate results from their simulations.

I don't know if you have any confusion about this, but I am laid up
after a hip surgery and have nothing better to do... lol


I assume one will just have to work with full working examples and read
through and them do small hardware projects using the knowledge and
code from prior working projects, and see how things turn out.
At some point I expect that things will start making sense and one can
start making small hardware projects without copy and paste, but that
point is nowhere here for now.

I started looking around for websites that offer simple exercises to
learn this.

Perhaps we can share some ideas on exercises we come up ourselfs.


At this time, I have two things I want to rey out:
- first, an I/O extender with SPI.

The SPI-protocol is not that complex and looks to me like a nice example
of "clocked" sequencial logic.

SPI is very simple indeed, but in general well thought out. The labels
clearly indicate the direction of signal flow and the clocking avoids
race conditions if used properly. The down side is that it is a bit
more flexible than needed so it can be a bit tricky to set up.


I think it might be doable, to create a VHDL design/circuit that allow
you to set or clear output pins on a FPGA/CPLD, based on commands
issued via SPI (from a microcontroller).

When you say "commands", usually the I/O bits are set/cleared directly
from the data shifted through the SPI port. There is normally the shift
register that receives the serial data (and provides for shifting data
out) which is transferred to the output register when the select line is
deasserted.


- a lot more difficult (perhaps as a "final exercise") is this:
https://www.youtube.com/watch?v=35zLnS3fXeA

This is a very simple broadboard based 8-bit processor (which seams to
be the "SAP" architecture used in quite a number of text-book on
microprocessor architecture) completely implemented in 74xx ICs.

That might be an ok project, but when it is done, what do you have? Just
an exercise. You might want to design some pieces that will be useful
to you in the future.


I currently how no idea how easy or difficult this will be, but perhaps
duplicating this in VHDL would be the ultimate "final test" exercise :-)




Do you -or somebody else- have ideas for exercises that might be
interesting to learn how to solve actual real problems with logic?

A reasonably simple example would be a basic, fixed size UART, say 8
bits, no parity, one stop bit. Design the transmitter and receiver
separately and test by connecting them together and shipping characters
across. Equally important is the test bench used to test your design.
You need to learn how to construct simple and yet powerful test benches
to stimulate your designs and verify the output. It is not uncommon for
the test bench to be as complex as the design you are testing, but
hopefully can be done more simply. In this case you can use the UART
transmitter to test the UART receiver and vice versa. The test bench
only needs to stimulate the parallel input/output and the control
strobes. It also does not need to be synthesizable and so can be
written more like a standard sequential program.

Once you have that working correctly, you can add programmable controls
for the word size, parity and stop bits. That gets a bit more complex
and your test bench will be more complex as well.

Both of these exercises will result in useful code. Often you can use a
simple, fixed size UART in your designs. Other times you will need a
programmable UART so it can be configured by software or changed for
different modes of operation.

Just a thought.



--

Rick C

kristoff
Guest

Sun Jun 12, 2016 3:51 am   



Kevin,



On 11-06-16 22:30, KJ wrote:
(...)
Quote:
Short answer is that if you ever feel the need to use both edges of
the clock...most likely you're not going about your design in the
correct manner. Synchronous logic design not only uses only one
clock, but only one edge of that one clock. Having said that, there
are cases when both edges are used and that is the correct thing to
do...but what you've described so far is not an example.


Very valuable advice.

Thanks! :-)



Quote:
Kevin Jennings
Cheerio! Kr. Bonne.


rickman
Guest

Sun Jun 12, 2016 5:19 am   



On 6/11/2016 5:51 PM, kristoff wrote:
Quote:
Kevin,



On 11-06-16 22:30, KJ wrote:
(...)
Short answer is that if you ever feel the need to use both edges of
the clock...most likely you're not going about your design in the
correct manner. Synchronous logic design not only uses only one
clock, but only one edge of that one clock. Having said that, there
are cases when both edges are used and that is the correct thing to
do...but what you've described so far is not an example.

Very valuable advice.


Your SPI interface is one of the places where both edges of the clock
*will* be used. When exchanging data externally you can't control the
clock skew enough to use the same clock edge for shifting data out and
shifting data in. So data is clocked out on one edge and in on the
other to assure adequate setup and hold times.

There are also some interfaces that specify the transmission of data on
both edges of the interface clock. Typically a 2x clock is used, but
you can also use a 1x clock with two sets of FFs clocked on opposite
clock edges. SDRAM memory interfaces typically do this and extra FFs
are included in the IO blocks of many FPGAs for this purpose.

Internally this would never be used in an FPGA.

I had a discussion once with someone laying out a CPU design who was
using the negative clock edge in a pipeline to increase his setup and
hold times. I tried to explain to him that this does not improve the
setup and hold, but in fact reduces the slack time because within 1
clock cycle two setups and two hold times have to be met. Maybe I
wasn't understanding what he was doing, but we never came to an agreement.

--

Rick C

rickman
Guest

Sun Jun 12, 2016 11:01 pm   



On 6/11/2016 3:05 PM, kristoff wrote:
Quote:
Hi Rick,

On 11-06-16 16:00, rickman wrote:

My question was in the first place intented to get an idea of how to do
syncronous design.

My bad, see below. I think you are doing pretty well.

No problem. :-)


Last week, I talked to somebody who works in a company that does ASIC
design and he said that -althou VHDL is a high-level language- you need
to keep in mind that this all gets turned into hardware.

"always try to understand how the hardware that actually does the job
actually works".


I used to promote this. I think it is useful for sure, but I don't know
it is essential. I was helping a software guy get up to speed on VHDL
and he was able to develop a "Hello, world" program without really
knowing how the hardware would work. He then went on to design the
system his boss needed for a demo to the customer.

I started out thinking you needed a knowledge of gate level logic
principles and an idea of the register level logic you wanted to create.
He showed me these are far from essential. These are very useful when
you wish to optimize a design either for size or speed. But even more
important is familiarity with the tools you are using.

--

Rick C

KJ
Guest

Mon Jun 13, 2016 4:15 am   



On Saturday, June 11, 2016 at 7:19:52 PM UTC-4, rickman wrote:
Quote:

Your SPI interface is one of the places where both edges of the clock
*will* be used. When exchanging data externally you can't control the
clock skew enough to use the same clock edge for shifting data out and
shifting data in. So data is clocked out on one edge and in on the
other to assure adequate setup and hold times.

Yes, and SPI is the type of example I had in mind where you might mistakenly think going in that you need to use the SPI Clock as an actual clock signal to clock some register(s), but you don't. SPI clock edges can be determined by sampling with the free running system clock unless the two clocks are close in frequency, which many times they are not. By using the system clock to clock registers rather than SPI clock you avoid clock domain transfers further down the road.


Kevin Jennings

rickman
Guest

Mon Jun 13, 2016 8:46 am   



On 6/12/2016 10:15 PM, KJ wrote:
Quote:
On Saturday, June 11, 2016 at 7:19:52 PM UTC-4, rickman wrote:

Your SPI interface is one of the places where both edges of the clock
*will* be used. When exchanging data externally you can't control the
clock skew enough to use the same clock edge for shifting data out and
shifting data in. So data is clocked out on one edge and in on the
other to assure adequate setup and hold times.

Yes, and SPI is the type of example I had in mind where you might mistakenly think going in that you need to use the SPI Clock as an actual clock signal to clock some register(s), but you don't. SPI clock edges can be determined by sampling with the free running system clock unless the two clocks are close in frequency, which many times they are not. By using the system clock to clock registers rather than SPI clock you avoid clock domain transfers further down the road.


I've never done it that way. SPI can be pretty fast and you need a
clock significantly faster to make it work that way. I implement the
shift register as clocked by the SPI clock and then cross the clock
domain with a handshake. Then your internal clock only needs to be fast
enough to receive the data words.

--

Rick C

kristoff
Guest

Wed Jul 20, 2016 3:59 am   



Hi Rick,


A follow-up on a thread of some month ago :-)



On 11-06-16 21:24, rickman wrote:
Quote:
A reasonably simple example would be a basic, fixed size UART, say 8
bits, no parity, one stop bit. Design the transmitter and receiver
separately and test by connecting them together and shipping characters
(...)



OK. I did some work on other stuff inbetween, but I finished the UART
sender and UART receiver. I dropped it on my github account:
https://github.com/on1arf/vhdl-exercises

I tested the code not by simulation but with an test setup of a altera
fpga and a mapple mini clone (STM32F103-based).



(The UART receiver does seams to "slip" characters from time to time, so
that is something I need to look at) :-(



I do have two questions:

1/
In uart_receive, there are four signals that are triggered on a positive
or negative edge, so I created four small edge-detection processes.
(nothing special, just compair in signal with the same signal the
previous clock-cycle).


As I use the same code four times over, for me - as a programmer- it
would be logical to create a function or an object for this; but I don't
know how to do this in VHDL.

The problem here is that there is a data (the value of the input signal
the previous clock-cycle) that must be kept between iterations of
calling the function , i.e. a "static vars" in C linguo.

But -as far as I have found in the documentation about VHDL functions-
local signals in a function in VHDL do not maintain state inbetween
iterations and I see no way to define "static" local signals.


As a result, uart_receive.vhd has four edge-detection functions, with
all data stored as "global" data. Note very clean :-(



Now I cannot really image that VHDL does not have a way to store "code"
that maintain state inbetween iterations.

So how do you do this?



2/
I am now working on a FIFO-buffer to make the UART_receiver more robust.

Do I need to add the FIFO buffer in the same VHDL-file (the same
architecture) as the UART_receiver code; or is there a way to store the
fifo-buffer VHDL-code in a seperate file.

Then how do I "include" and "call" the FIFO vhdl-code in the
uart_receive circuit?



> Just a thought.

A very interesting exercise, I must say. :-)


I am now working on the 4 byte FIFO buffer for the UART. After that,
I'll try the SPI stuff.



Cheerio!
Kr. Bonne.

rickman
Guest

Wed Jul 20, 2016 6:22 am   



On 7/19/2016 5:59 PM, kristoff wrote:
Quote:
Hi Rick,


A follow-up on a thread of some month ago :-)



On 11-06-16 21:24, rickman wrote:
A reasonably simple example would be a basic, fixed size UART, say 8
bits, no parity, one stop bit. Design the transmitter and receiver
separately and test by connecting them together and shipping characters
(...)


OK. I did some work on other stuff inbetween, but I finished the UART
sender and UART receiver. I dropped it on my github account:
https://github.com/on1arf/vhdl-exercises

I tested the code not by simulation but with an test setup of a altera
fpga and a mapple mini clone (STM32F103-based).



(The UART receiver does seams to "slip" characters from time to time, so
that is something I need to look at) :-(



I do have two questions:

1/
In uart_receive, there are four signals that are triggered on a positive
or negative edge, so I created four small edge-detection processes.
(nothing special, just compair in signal with the same signal the
previous clock-cycle).


As I use the same code four times over, for me - as a programmer- it
would be logical to create a function or an object for this; but I don't
know how to do this in VHDL.

The problem here is that there is a data (the value of the input signal
the previous clock-cycle) that must be kept between iterations of
calling the function , i.e. a "static vars" in C linguo.

But -as far as I have found in the documentation about VHDL functions-
local signals in a function in VHDL do not maintain state inbetween
iterations and I see no way to define "static" local signals.


As a result, uart_receive.vhd has four edge-detection functions, with
all data stored as "global" data. Note very clean :-(



Now I cannot really image that VHDL does not have a way to store "code"
that maintain state inbetween iterations.

So how do you do this?


Two ways to do it. One is to create an entity which contains the code
as well as the signal declarations of any signals you need for internal
storage. Then the entity is instantiated four times.

Or you can use a procedure call. A procedure is sequential code and you
can declare variables which *can* remember state between invocations if
coded so they are used before being set. The variable can only be
"seen" from outside of the procedure call by assigning its value to a
signal in the parameter list.

You might be able to use a function rather than a procedure if it only
needs to return a single item (which can be an array or record).


Quote:
2/
I am now working on a FIFO-buffer to make the UART_receiver more robust.

Do I need to add the FIFO buffer in the same VHDL-file (the same
architecture) as the UART_receiver code; or is there a way to store the
fifo-buffer VHDL-code in a seperate file.

Then how do I "include" and "call" the FIFO vhdl-code in the
uart_receive circuit?


Separate entities can be defined in separate files or the same file.
Functions, procedures and data types can be defined in libraries.
Libraries are included with "use" statements.


Quote:
Just a thought.

A very interesting exercise, I must say. :-)


I am now working on the 4 byte FIFO buffer for the UART. After that,
I'll try the SPI stuff.



--

Rick C

Goto page Previous  1, 2

elektroda.net NewsGroups Forum Index - VHDL Language - "rising_edge(clk)" and delay

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map