This is for an ADC. What I'm trying to do: when adc_sample goes low, grab hold of a value. Then when adc_data_en goes high, compare it with adc_data. Here's what I have so far:

    property adc_deduces_voltage;
        bit [7:0] true_voltage;

        @(negedge adc_sample) (`true,true_voltage=input_channel) 
        ##1 @(posedge adc_data_en) 
        // Values are sampled in the prepond region. This would be before
        // adc_data_en is high, giving us old values. To make up for this, wait
        // for one more clock cycle so that sampled values will be just after
        // adc_data_en is high.
        ##1 @(posedge clock) (adc_data == true_voltage, $display("Pass. Actual: %d, ADC: %d", true_voltage, adc_data);
    endproperty
    assert property (adc_deduces_voltage);

Note the comment I inserted. The hacky bit of my code is waiting for the next rising edge of the clock so that I can avoid the issue of things being sampled in the prepone region.

Any thoughts on improving this? Is there a better way to do this?

Also, what if I wanted to do something like: wait for negedge adc_sample, then posedge adc_data_en then 20 clock cycles later carry out checks?

So I'm new to FPGAs. I've got a project that runs fine at 100MHz on an Altera chip. I'm trying to downscale to an iCE40UL. It runs fine at 70MHz, but bumping to 100MHz and certain clocks act up/don't show up at all.

So in theory, I know there's an issue with signal buffering or routing or something, but I've never actually had to deal with this practically, and I'm struggling to find any online resources.

The iCEcube2 software comes with a floor planner that helps visualize which blocks are being used that looks like this.

Here you can see my (buffered) 100MHz clock is feeding a lot of blocks. Probably part of the issue.

I can move things around on this floor planner, but in doing so, what is my goal for optimization? Do I want to literally shorten all the traces? (as in, do the blocks in the floor planner indicate their literal locations on the chip?) or what else is the goal?

Unfortunately, I don't think I have access to any simulation tools unless there's something I'm missing, iCEcube2 is very barebones.

Hi there!

I'm having a look into creating a FPGA system with purely open standard and open source IPs (as well as open source code on my part). So far I have landed on a really good journal article looking into different open source IPs for the RISC-V open standard here: https://ieeexplore.ieee.org/document/8760205.

But now I have realized that I need some sort of display interface and can't find anything! I have read that DisplayPort is open-source, but I am pretty sure this only relates to the interface protocols and not the actual hardware itself. I may be wrong on this but I haven't been able to easily find anything on their standard licensing rules, other than a licence for their logo and brand name which doesn't seem very compatible with the ethos of the project.

Perhaps USB-C is the best solution.

Is anyone aware of any display interfaces that I could implement? I do not have a lot experience in video interfaces so would like some suggestions from people who likely know a lot more than I do :)

This is an open-source FPGA project I've been working on for several years now. It's an Ethernet switch for FPGAs, but you can mix-and-match the usual RMII/RGMII/SGMII interfaces with unconventional options like a plain old UART.

My company uses it internally, but we decided to release it as open source. (Currently LGPLv3 but open to other weak-copyleft suggestions.)

Among other things, we've recently incorporated some new technology that allows picosecond-accurate timestamps to be compared across different digital clock domains. You can think of it as a group of NCOs that all track the same best-fit line.