How to use and manage memory with my FPGA?

[GalD101]

Hi, I have a goal of building a cheap CCU (coincidence counting unit) using my xc7s25csga255-1 spartan 7 (link).

I want to be able to record all the pulses and save them (using a photon detector device that will connect to the FPGA).

To start with something simpler, I want to record how many times I press a button and measure the time between each click.

When I'm done, all the data that I recorded should move to an external computer.

How can I achieve this?
 

edit: I need to implement a CCU (coincidence counting unit) using my xc7s25csga255-1 spartan 7 (link). I'm using Verilog and working with Vivado.
I want to be able to record all the pulses (using a photon detector device that will connect to the FPGA) from 2 channels and if both of them are active at the same time, record that (I think using an and gate) and also save when it happened. I want all the data that was recorded to be transferred to a computer (it can happen during the experiment or after it). I thought of using UART to send data but to my understanding, it's not fast enough.
The whole operation should take about 30 seconds.
I might be wrong but I think that in order to achieve this, I need to first write to BRAM as I run the experiment, and then transfer the data to a computer (I think that writing to BRAM is faster than transforming the data to a computer I might be wrong).

Edited August 23, 2023 by GalD101
mistake

[D@n]

The counting part is the easy part.  Beware of clock domain crossings and button bouncing.

Moving the data to an external computer will take some work.  How much work depends on how you wish to to it.  Pushing a counter through a serial port isn't all that hard to do.

Dan

[zygot]

3 hours ago, GalD101 said:

To start with something simpler, I want to record how many times I press a button and measure the time between each click.

This might not be simpler. Mechanical buttons and switches feature contact bounce that can easily last for milliseconds. You need to account for this. Usually this is done with a "debounce" module or entity... oh now I see that Dan mentioned this already.

the UART is the easiest way to pass data between your FPGA board and a PC.

Whether you are timing a photonic sensor or a button, you will be doing asynchronous sampling at some appropriate clock rate that is unrelated to your DUT (device under test).

On idea is to detect your pulse edges and save a timestamp and edge direction ( rising or falling ) to a FIFO.

All of this can be done in VHDL or Verilog pretty easily and take up very few resources, depending on how much data you need to collect.

Edited August 20, 2023 by zygot

[Guest]

Ho @GalD101

It is smart to build toward your final implementation in stages of increasing difficulty.

However, it's also important to understand the final application you have in mind from the get-go. Some questions for your application:

- what is the maximum event rate you want to be able to handle?
- are your events reasonably smooth, or do you expect bursts of activity? If yes, can you describe it?
- how many channels do you need?
- what is the time bin resolution you need?
- do you want to make a streaming solution, or have separate capture/transfer stages?

The answer to those questions determines what the best solution direction is.

A streaming solution is easier to implement, and cleaner (because your recording time is unbounded). But it can only work if your communication chain is able to keep up, even in the presence of any bursts of activity.

Your CMOD-S7 has no memory external to the FPGA. This means you will use the on-chip BRAM for buffering (in case of a streaming solution) or storage (in case of capture/transfer). In either case, you should be using a FIFO. As luck has it, Xilinx provides validated FIFO implementations for you, including versions that can do clock domain crossing, if so desired. Question: do you understand what "clock domain crossing" means? If not, we'd be happy to explain.

Some auxiliary questions:

- which HDL would you like to use, VHDL, Verilog, or something else?
- the computer you want to connect to, what kind of an OS is it running? I know from experience that Linux machines can handle much higher baud rates than Windows machines without data loss.

Cheers, Sidney

 

 

[GalD101]

21 hours ago, zygot said:

Whether you are timing a photonic sensor or a button, you will be doing asynchronous sampling at some appropriate clock rate that is unrelated to your DUT (device under test).

I thought of implementing synchronous sampling since I thought that asynchronous sampling is slower and not fast enough for my project.
I am now trying to learn how to save to memory.
also apologies for the poor explanation of my problem, I just never used FPGAs before and never learned verilog or any other HDL language such as VHDL

[zygot]

1 hour ago, GalD101 said:

I thought of implementing synchronous sampling since I thought that asynchronous sampling is slower and not fast enough for my project.

Asynchronous sampling means that the low-high and high-low transitions of your external signal have no phase relationship to the clocking of your FPGA logic. Whether or not asynchronous sampling is appropriate depends on how fast your logic can be clocked and the toggle rate or your external signal. For something like a user push button, synchronous sampling is not possible because you don't have an input clock associated with the button signal to define a fixed phase relationship. I imagine that this is the same with your photon detector. If a sensor provides both a clock and signal data, then you can so source-synchronous sampling of the data, as long as the external clock can be connected to a clock-capable pin of your FPGA.

1 hour ago, GalD101 said:

I just never used FPGAs before and never learned verilog or any other HDL language such as VHDL

FPGA design is really digital logic design, so developers need to have basic knowledge of designing with real logic devices. In the early days of Xilinx programmable logic the tools only supported a schematic capture method of telling the tools how you wanted your design to function. Later, HDLs were supported so that your design could be presented in a text format.

FPGA vendor tools such as Quartus and VIvado provide limited free IP, basically pre-designed functional blocks of HDL code, that allow implementing a limited range of design functionality, using a GUI schematic-like interface, without requiring the user to know anything about the source code. Eventually, developing skill with an HDL becomes a requirement if you want to do implement a custom design.

Edited August 21, 2023 by zygot

[D@n]

Welcome to hardware design.  You now get to decide which memory to use.  In general, there are four places you can store results: Off chip, block RAM, distributed RAM, and in Flip Flops (FFs).  The first of these three are typically called "memory", whereas storage isn't really "random access", so the term "memory" is rarely used to describe it.  Off chip memory comes in many varieties as well, such as SRAM, SDRAM, DDR SDRAM, DDR[2-5] SDRAM, etc.

Of these options, FFs seem to be the most appropriate storage location for a counter.  Such a counter might look very much like this one, used to measure one clock rate in terms of another.  It's quite similar to what you wish to do.

Dan

[Guest]

Hi @D@n

I don't think a counter will suffice for his application. We're doing coincidence counting all the time in the lab, and you'd normally use a timetagger and post-processing.

A "coincidence" is normally not a boolean thing; what you want to get out is essentially a correllation spectrum of two (or sometimes more) channels. For convenience you'd limit the delta-t's for which you'd want to see the spectrum.

You could implement a coincidence counter in the FPGA, but it's actually pretty cumbersome. Often time you want to do things like masking the channels, or only considering events in a time window relative to some trigger. if at all possible, it is much more flexible to use a timetagger and do coincidence extraction in post-processing, because that gives you a lot more freedom w.r.t. optimizing the details of your experiment, and allows you to re-analyze the raw event data in different ways.

Of course we don't know details of @GalD101 's experiment, so I may be overthinking this -- but I'd bet a tiny sum that his/her problem is better tackled with a timetagger if we knew what they are trying to accomplish, precisely.

 

[Guest]

Hi @GalD101

> I just never used FPGAs before and never learned verilog or any other HDL language such as VHDL

A word of warning: FPGAs are a pretty complicated and knowledge-intensive technology, and there's also the hurdle of learning to tame the beast that is a modern HDL development environment like Vivado.

Learning this from scratch to the point where you'd have a working device will take you several months, if you're talented and already have helpful low-level programming experience, eg in microcontrollers.

It's a boatload of fun, so if you're up for that, go for it. But if you're just looking to get something working soon, I'd advise you to consider a different approach.

[zygot]

On 8/20/2023 at 8:03 AM, GalD101 said:

I want all the data that was recorded to be transferred to a computer (it can happen during the experiment or after it). I thought of using UART to send data but to my understanding, it's not fast enough.
The whole operation should take about 30 seconds.

This might require a lot of event storage, or not much at all. It depends on how many signal transitions occur over the experiment time interval and what you store. It also depends on whether the signal activity is bursty, intermittent, constant etc. A UART interface at a 921600 baud rate can do 80-90 K bytes/s without flow control assuming the your PC uses enough buffer storage. At 12 Mbaud a UART can do a little over 1 MB/s with hardware flow control. As long as the data being sent doesn't outpace the interface a small FPGA buffer using BRAM might be sufficient. There are often faster PC interfaces available on FPGA platforms for streaming data at higher rates. A bit if cleverness in a design architecture can overcome data transfer interface limitations performed in a simplistic manner.

I'd say that something like an Analog Discovery product might be what you want to look at but the functionality of these can't be changed by the user. The Red Pitaya is a similar product to the ADx product line and allow for the user to add custom logic. The problem with that platform is that it's not well supported and hard to work with. For someone with good FPGA development experience, and some knowledge about the expected behavior of the hardware that you are measuring this is a 2 day project. Learning how to do FPGA development using Verilog or VHDL isn't a 2 day project.

[zygot]

36 minutes ago, reddish said:

Often time you want to do things like masking the channels, or only considering events in a time window relative to some trigger. if at all possible, it is much more flexible to use a timetagger and do coincidence extraction in post-processing

The key part of this thought is "considering events in a time window relative to some trigger". Sounds simpler than it usually is, especially when using an FPGA platform. Analyzing what's taking place inside a logic implementation in an FPGA is the easy part.

Physicists have been using Time-to-Digital techniques to measure relative event times to picosecond resolution for a long time, often for photonic measurements. These can 'mostly' be implemented in logic, even an FPGA device.

 

Edited August 21, 2023 by zygot

[zygot]

57 minutes ago, reddish said:

I don't think a counter will suffice for his application. We're doing coincidence counting all the time in the lab, and you'd normally use a timetagger

A simple counter might suffice as a timetagger. I do this all the time to debug FPGA applications running on hardware where things like the ILA just don't work.

[Guest]

Hi @GalD101

I had a load of relevant questions for you but you only answered some of them, and by editing your original post (which I nearly missed). Please try to answer all of them, because they are all relevant. Especially the expected detection rates on both detectors is an important number, as is required time resolution. I cannot provide good advice to you if you don't answer those questions.

Your idea to do a coincidence measurement by AND'ing the outputs of your single-photon detectors is too simplistic. In that way your "coincidence rate" will depend on the length of photon detection pulses sent out by your SPDs, which is clearly not what you want -- only the first edge of your photon detection pulse coming out of your SPD has relevant information. So this is not how photon coincidence measurements are done in photonics. The outcome of a coincidence measurement should be a spectrum with the horizontal axis being Δt, and the vertical axis being observed coincidence rate (or rates) with that Δt. Before you proceed, make sure you understand that, because otherwise you're probably approaching the experiment all wrong.

To give advice, it is also important to understand why you're doing these measurements. If you're doing this as work for a PhD thesis, postdoc work, or industry work, you should get all the details right, since you are striving for publishable results (if academic) or real data that will be used to make business decisions. Alternatively, if you're doing this as a lab course for a bachelor or master's degree, the requirements are much lower -- the primary goal then is for you to learn stuff and get some experience doing experiments, and in that case you can cut some corners (with a preference for cutting corners consciously rather than by accident).

For proper analysis (e.g. in case you're working towards a publishable result), you will need to know several behavioral features of your detectors: dark count, dead time and behavior near the dead time window, and quantum efficiency at the wavelength you're using. Some of those can be gleaned from / estimated from the data sheet, but it's best to measure them as part of your experimental preparation. That way you'll also establish that both detectors are actually behaving in the same way, which is probably a prerequisite for your experiment.

Also of note: you can buy off-the-shelf equipment that make these kinds of measurements much easier. They are called timetaggers and they will produce a stream of events (over USB or Ethernet) to a computer with super high resolution (you can buy instruments with RMS uncertainty in the picosecond range if you fork over the money). The only valid reasons to try a roll-your-own solution are if you're budget-constrained (the off-the-shelf hardware costs upward of 10k USD), or if you're trying to do this as an educational exercise. Again, this depends on the context of the challenge you've been given. There are institutions that would balk at such an investment, and there are institutions for which a 10 k$ device is not an issue at all. I don't know which applies to you.

 

Edited August 21, 2023 by reddish

[GalD101]

Hi @reddish, first of all, thank you for the help. I didn't answer all of your questions since I didn't really understand them. I'm a first-year physics and CS student so I don't have a deep understanding of SPD or FPGA yet. I did talk with my professor and that's what we concluded:

On 8/20/2023 at 10:07 PM, reddish said:

- what is the maximum event rate you want to be able to handle?

I think that we need to measure the maximum event rate according to this link (this is the SPD we have)

On 8/20/2023 at 10:07 PM, reddish said:

- are your events reasonably smooth, or do you expect bursts of activity? If yes, can you describe it?

we have a CW laser so I think the events would be reasonably smooth

On 8/20/2023 at 10:07 PM, reddish said:

- how many channels do you need?

I would like to use 2 and if that would work, I'll try to use 3

On 8/20/2023 at 10:07 PM, reddish said:

- what is the time bin resolution you need?

I'm not sure I think it should approximately be the recovery time of the sensor between each detection.

On 8/20/2023 at 10:07 PM, reddish said:

- do you want to make a streaming solution, or have separate capture/transfer stages?

 

according to what you said, it would probably be a better idea to make a streaming solution since it would be easier.

On 8/21/2023 at 10:06 PM, reddish said:

if you're doing this as a lab course for a bachelor or master's degree

you are correct, I'm doing this as a small project mostly to get some experience doing experiments (I'm in my first year, bachelor's degree).

On 8/20/2023 at 10:07 PM, reddish said:

do you understand what "clock domain crossing" means?

not really but after reading a bit about it, it seems to be the issues that arise when data from one flop transfers data to another with a different clock

in general, since you seem to be familiar with coincidence counting, do you have any tips on what should I do? I tried reading a lot online and I built very basic projects in Verilog. After reading a bit, I don't think I'll be able to finish this in less than a month but I am very interested in learning more about FPGA and how to program it

Edited August 23, 2023 by GalD101

[Guest]

Hi @GalD101

Thanks for providing context. It can be a neat little project for sure to learn a lot of stuff about experimentation and FPGAs. From my side: I am a computer science guy by training but I have spent the last five years or so doing optical experiments in quantum-related research. My responsibility there is mostly to support the physicists who think up experiments, then take care of the "computer stuff" to make it happen. This varies from using Analog Discovery devices for basic stuff (which is why I visit this forum), very high-end instruments (RF sources, lasers, timetaggers), mostly using Python; and sometimes FPGAs and microcontrollers if the functionality needed cannot be accomplished with off-the-shelf stuff.

Now that I know a bit of background I will have to think a bit about what is feasible within a month or so of your time, given that you're a relative newbie to this stuff (nothing wrong with that -- we all have to learn it sometime).

It would help if you can share a sketch of the experiment that you plan to do. Then we can brainstorm a bit, perhaps come up with a plan.

[GalD101]

@reddish

Hi, this is really a simplified sketch of the experience and it's not 100% accurate but it should be enough for my part

we start with two photons that go through a change in their energy level (by going through some sort of medium - a crystal) and then they both reach a corresponding detector.

Also, excuse my awful handwriting.
this is the transcript of what's written:
We want to know when we have a "coincidence", that is, when both detectors are on, within a certain time interval.

 

Why do we want to check if there are coincidences? because if there is a coincidence, it means the  2 photons were created together as a pair.

 

Issues that may arise:

• How would we choose the time interval? (We can choose a sufficiently large time interval such that every detection would count as a coincidence)
• Following the previous issue, it seems that we may have false positives (coincidence detected but in reality, there was no coincidence) as well as false negatives (coincidence was not detected but in reality, there was a coincidence - "missing a coincidence")
• HDLs are not programming languages (harder)
• It's not just an AND gate
• Clock management and things lick clock domain crossing

CCU sketch.pdf

Edited August 24, 2023 by GalD101

[GalD101]

there is a more detailed explanation here. or in the PDF

2005 Interference with correlated photons.pdf

[Guest]

Hi @GalD101

Thanks that's useful. To be precise, which of the five experiments described in the paper will you try to replicate? And will you follow the paper pricisely, or are you planning variations?

Now, as to what is feasible using an FPGA:

Step 1. Using just an FPGA, it is relatively easy to hook up an SPD and detect single photon events.

On the hardware side, this involves making sure that the voltage level output by the SPD is compatible with the voltage input of the FPGA. If you want to do it properly, it would be necessary to make sure that the impedance of the receiving end matches the impedance of the cable coming out of the SPD (usually 50 Ohms), to make sure you don't get reflections of the detection pulses. This is more-or-less optional if the SPD has an output impedance of 50 Ohms, as it will absorb any reflections in that case.

(A first learning goal for you could be to understand what I'm saying in terms of cable, source, and sink impedance, here. It will serve you well in doing experiments later on; bad treatment of impedance can cause a lot of grief in the lab.)

On the software (HDL) side, this is already a lot more involved. The most challenging part will be to write a bit of VHDL or Verilog to transfer information from the FPGA to the computer. The only feasible way to do that (given your expertise) is via a serial interface. You will write bytes from inside your FPGA to an FPGA output pin that is connected to an FTDI chip on your development board. This FTDI chip will send this data to the PC via USB, where you can receive it using a serial port reading program, for further analysis.

Step 2. Capturing coincidences.

Your FPGA will run at a certain clock frequency; typically, somewhere between 50 and 125 MHz. This means you will be able to look at your input pins once every 8 to 20 ns. That's /probably/ fast enough to detect coincidences. If you can get this to work within a month (starting from where you are now) that's already quite an accomplishment. We can do better though, see Step 3. But first, let's look at this.

A nice way to do detect coincidences is the following pseudo-algorithm:

At startup, initialize a counter t_now to 0. This will count clock cycles.

On every FPGA clock cycle:

* ch1_flag = are we seeing a rising edge on channel #1 (i.e., was it 0 in the previous cycle, and 1 now)?
* ch2_flag = are we seeing a rising edge on channel #2 (i.e., was it 0 in the previous cycle, and 1 now)?
* if (ch1_flag): t_most_recent_ch1_photon = t_now
* if (ch2_flag): t_most_recent_ch2_photon = t_now
* if ( (c1_flag or ch2_flag) and abs(t_most_recent_ch1_photon  - t_most_recent_ch2_photon ) <= THRESHOLD:
     transfer_to_pc(t_most_recent_ch1_photon , t_most_recent_ch2_photon)
* increment t_now.

Here, THRESHOLD is the maximum delta-t you'd ever be interested in; photons that are more than this number of clock cycles apart are definitely NOT correlated photons.

For the moment, let's pretend the transfer_to_pc function actually exists. In actuality, you would push a detected coincidence into a FIFO (built on top of the FPGA's internal memory) on the detection side, and at the output-side of the FIFO, you would pull those events from the FIFO, and write some serial message (using the stuff we did in step 1). This may involve a clock-domain crossing, but we can probably do without for simplicity. (We'll discuss this if/when we get here).

Please let me know if you understand all this. If not, ask for explanations. Some stuff you could google (like "what is a fifo") but other stuff, not so much.

Step 3. Increasing the time resolution

You're probably not going to get here in a month, but let's pretend that you do.

The next step could be to increase the time resolution of your detector. 20 ns or 8 ns is super short on human timescales, but for your coincidence detections, you would like shorter time bins.

This you can do (even with your basic Spartan-7 FPGA) by using a "deserializer". This is a dedicated piece of hardware sitting next to each of your input pins inside the FPGA, that allows you to capture input events at a much higher rate than what your regular FPGA logic is capable of. For example, if your FPGA runs at 100 MHz, it would be possible to let this "deserializer"  run at 800 MHz. It would then produce a single 8-bit byte every 10 ns, where each bit shows the status of the input pin at a resolution of 1.25 ns.

But this is getting pretty advanced. You should be happy to reach step (2) in the project.


Ok -- that is, I think, a reasonable basic plan to approach this.

Because you are new to this, however, there is also a step 0, which is, to install the Vivado software and learn enough of your favorite HDL (Verilog or VHDL) to make an LED blink on the FPGA board.

Now I think I could talk you through steps (0), (1), and (2) in a few weeks' time, but the first thing you need to do is answer the question if a 10 nanosecond detection resolution will be enough to establish co-incidence. To determine that you need to make some calculations, and use the realization that you can attenuate the laser light to a certain level, and that "random" photons will behave as a Poisson process.

You should also check with your professor that they agree with this basic plan and that they agree that this project is a question of "let's see how far we can get in a month", without a guarantee for success. If they are feeling adventurous, they should agree, but it's up to them in the end.

Don't forget that, apart from learning FPGA's, you will also need to spend a lot of time in the lab to get the rest of your setup working. So you're in for a pretty intensive time if you're going to go down this path. Make sure you're not trying to bite off more than you can chew in your limited time budget.

Cheers Sidney
 

 

Edited August 24, 2023 by reddish

[zygot]

 

1 hour ago, reddish said:

Now, as to what is feasible using an FPGA:

I'm not sure how good a plan this is for someone with no experience in using and digital design, HDL or Xilinx tools, but it is a plan.

Don't trivialize the learning curve for implementing and debugging an attempt this as a first project.

Don't trivialize the hardware design issues of connecting external equipment to a general purpose FPGA board.

Before you can assess your storage requirement and a suitable way to convey collected data to a PC, you likely need to perform your tests first using expensive lab equipment. You need to set some reasonable parameters for your design specifications.

It's certainly possible to use ISERDES to sample source-synchronous inputs at very high data rates. I suspect that doing this for 2 channels will be a bit more complicated than you anticipate.

It might work out; I have no opinion about that.

[Guest]

Hi @GalD101

Here's an interesting, relevant picture: the output of an SPD on an oscilloscope with quite a few photons coming in (about 20 million per second). A lot of typical behavior can be seen in this one image...

We're triggering on the falling edge of a photon-detection event here. Note that the space before and after the photon detection is empty. This is because the detector is essentially blind for a small period of time after detecting each photon. This is called dead time in the device's datasheet.

Another curious phenomenon is that you see a number of photon detections right after the dead time has passed relative to the triggering event, visible as a bright band. This *bunching-up* effect happens because photons that arrive shortly before the dead-time window passes can still trigger a detection event, but they will do so only after the dead-time window closes. This effect can really throw off statistical analysis of the data, so it's best to discard all photons that arrive within, say, 1,5x the dead-time window of the detector, and reflect this discarding choice in your mathematical model of the experiment. Otherwise, you would have to model this bunching-up behavior, and that's complicated.

Lastly, it is useful to see that for our SPD, the duration of a photon is only about 10 ns. This means that, in order not to miss detections, you will have to sample once every 5 ns, or faster. This is not trivial, so I hope your photon detector shows longer pulses (you should connect it to a scope to check). Otherwise, one way to handle this would be to use a pulse stretcher, to ensure that each photon detection is high for at least 2x your FPGA period, or to increase the sample speed of your FPGA.

All this is not to scare you, but please be aware that doing experimental photonics with FPGAs is decidedly non-trivial.

Cheers, Sidney



 

Edited August 24, 2023 by reddish

[zygot]

3 hours ago, reddish said:

Your FPGA will run at a certain clock frequency; typically, somewhere between 50 and 125 MHz.

For an Artix -1 speed grade device the maximum global clock buffer rate is 464 MHz. This is fastest that you can clock your design internally. For IOB clocking BUFIO maximum rate is 600 MHz. This the fastest rate that you can run the IO normally. For ISERDES it's 600 Mbps or 900 Mbps.  It doesn't matter what the external clock source frequency is.

These are the basic maximum capabilities of a typical low end FPGA device. Clocking a whole design implemented in a ARTY-A7 at 450 MHz will likely be problematic, but you can clock some of your logic at that rate and other parts of your design at a slower rate and meet timing closure.

[zygot]

1 hour ago, reddish said:

Lastly, it is useful to see that for our SPD, the duration of a photon is only about 10 ns.

You also see that the pulse has a rise time of 5.40 ns and a fall time of 8.10. This is with a scope of unknown analog bandwidth and a 1 GHz sampler. If nothing else, the scope picture should be telling you that capturing this SPD output is more than a simple digital exercise. Be careful of how you interpret oscilloscope signal renderings. Consider two of these that have arbitrary phase relationships on their leading and trailing edges relative to each other and, I assume any logic clock.

The picture doesn't tell us this, but I'd assume that the cable from the SPD is plugged directly into the scope input that's set for 50 ohm termination. Doing this with a cheap FPGA board using PMOD headers with a trace between the header and IO pin that's not ideally impedance matched and having a much less than ideal termination will be something to consider.

More importantly, consider that (if) the SPD doesn't provide a reference clock for defining phase relationships you will be doing asynchronous detection.. on 2 channels. Does an FPGA have the functionality to handle this? I don't have an opinion that I want to share. I would say that I'd think about doing the hard stuff using and external circuit so that I have a good idea of what the FPGA logic is seeing. It doesn't matter what logic is implemented in programmable logic if what it's working on is substantially different than the external signals.

In theory, someone with a lot of experience might be able to pull this off in a reasonable amount of time. It would take more effort to verify than implement I imagine.

Note that I have no experience using SPD type devices specifically.

Edited August 24, 2023 by zygot

[GalD101]

18 hours ago, reddish said:

To be precise, which of the five experiments described in the paper will you try to replicate?

For now, we will do the first one with no variations. Later on, we plan to do the rest.

18 hours ago, reddish said:

there is also a step 0, which is, to install the Vivado software and learn enough of your favorite HDL (Verilog or VHDL) to make an LED blink on the FPGA board.

I actually already did exactly this (blinking LED) as well as making the buttons turn the LED on (which is just one line 'assign led = ~btn)

18 hours ago, reddish said:

10 nanosecond detection resolution will be enough to establish co-incidence.

It will be enough.

p.s. Thanks everyone for the help! I really appreciate it

[Guest]

Hi @GalD101

Well, there's an issue.... You're doing Verilog, I only have experience with VHDL. And no intention of learning Verilog, I'm afraid.

I'm fine with you doing Verilog of course, but that will make it impossible for me to review your work effectively when you're stuck. We'd have to depend on others to help you out there.

> I actually already did exactly this (blinking LED)

Good. But getting the LED to blink is actually just the mechanics; more important is that you learn a few basic facts about Vivado, constraint files, what a signal is and how to think about signal assignments, and the difference between a combinatoric circuit and a sequential circuit. I would also like you to understand why it's important to register (i.e., put in a flip-flop) signals coming from the outside world. Also, it will be important that you are able to use the internal clock manipulation facilities of your Spartan-7 to derive a higher frequency from the 12 MHz crystal that the CMOD board gives you.

So to finish step (0), there's a little exam ... :) I'd like you to be able to explain, in your own words,

(a) the difference between a combinatoric and a sequential circuit.
(b) what a "signal assignment" does. Specifically, what is the value of a signal inside a clocked code block right after the assignment statement?
      (Here, I know how it works in VHDL, but I am unsure about Verilog. I suspect it to be very similar, but I cannot say for 100%.)
(c) the difference between combinatorial and sequential circuits.
(d) why registering externally generated signals that are asynchronous relative to your clock is always a good idea (even if your HDL allows you to not do that).
(e) how to annotate an external clock signal and external pins in the constraints file used by Vivado to place-and-route your design.

And (f), as a little practical check I would also like you to run your FPGA design at 100 MHz, and have the LED blink at 10 MHz, with a 30% duty cycle (This involves instantiating a Xilinx-specific MCMD or PLL block and configuring it), and to show the result on a scope. It won't look pretty (which is an interesting thing to realize), but it will give enough information to verify if you got the timing precisely right.

You need to really understand the stuff mentioned above to start with the next step, which will involve communication from the FPGA to your computer.

Let me know if you get stuck on any of these.

Cheers, Sidney

 

Edited August 25, 2023 by reddish

[GalD101]

On 8/25/2023 at 1:09 PM, reddish said:

(a) the difference between a combinatoric and a sequential circuit.

On 8/25/2023 at 1:09 PM, reddish said:

(c) the difference between combinatorial and sequential circuits.

 

What’s the difference between a and c?

From what I understand, in essence, a combinational circuit is a circuit that only depends on its input while a sequential circuit depends on the input as well as its previous output. So you can think of the previous output as some sort of an input as well

Edited August 26, 2023 by GalD101