Prev: Burn to an internal prom Spartan-3an
Next: Design passes synthesis and routing but fails on FPGA
From: glen herrmannsfeldt on 9 Jun 2010 14:37
Anssi Saari <as(a)sci.fi> wrote:

>> Sudhir Singh <Sudhir.Singh(a)email.com> wrote:

>>> I am just wondering if there are any standard ways of disabling an ip
>>> core after an evaluation period of say 30 days. I am trying to provide
>>> a potential customer a ip core but don't want them to continue using
>>> it after the eval license period expires. The core will run on Xilinx
>>> Spartan3 FPGAs.

(then I wrote)

>> Considering the ability to change the date on the computer,
>> it is pretty hard to stop people from using something past
>> a given date. Once the bit file is generated, it is pretty
>> much impossible.

> Well, at least the licensable Xilinx IP I've used included some kind
> of timer in the bitfile itself if there's no license, so that the
> block works for a few hours and then quits.

Yes, I had forgotten about the ones that count clock cycles.
But that doesn't help if you want a specific time or date.

Even so, one could probably find a way to disable the counter.
(I don't know if reset will reset the counter or not, otherwise
one can always reload the device.)

I was unsure from your original post if you meant the ability
to generate bitfiles, or the ability to use them.

If the device has internet access, you could use an NTP server
to get the date/time. That would take a lot of logic, though!

-- glen


From: General Schvantzkoph on 9 Jun 2010 16:18
On Tue, 08 Jun 2010 16:53:43 -0700, Sudhir Singh wrote:

> Hi Guys,
>
> I am just wondering if there are any standard ways of disabling an ip
> core after an evaluation period of say 30 days. I am trying to provide a
> potential customer a ip core but don't want them to continue using it
> after the eval license period expires. The core will run on Xilinx
> Spartan3 FPGAs.
>
> Any suggestions will be much appreciated.
>
> Regards
> Sudhir

Xilinx doesn't have a mechanism yet for generating an IP license, they
plan to have one that uses a new IEEE standard but that won't happen for
a year.

Altera does have tools that allow you to encrypt your source code and
then generate a flexlm license that can restrict the type of FPGA it can
go into, allow simulation only or just synthesis, and the time limits for
the IP. However once you've generated a bit file it's good forever, there
is no way to have a bit file that's time limited.
From: Gabor on 9 Jun 2010 18:12
On Jun 9, 2:37 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
> Anssi Saari <a...(a)sci.fi> wrote:
> >> Sudhir Singh <Sudhir.Si...(a)email.com> wrote:
> >>> I am just wondering if there are any standard ways of disabling an ip
> >>> core after an evaluation period of say 30 days. I am trying to provide
> >>> a potential customer a ip core  but don't want them to continue using
> >>> it after the eval license period expires. The core will run on Xilinx
> >>> Spartan3 FPGAs.
>
> (then I wrote)
>
> >> Considering the ability to change the date on the computer,
> >> it is pretty hard to stop people from using something past
> >> a given date.   Once the bit file is generated, it is pretty
> >> much impossible.
> > Well, at least the licensable Xilinx IP I've used included some kind
> > of timer in the bitfile itself if there's no license, so that the
> > block works for a few hours and then quits.
>
> Yes, I had forgotten about the ones that count clock cycles.
> But that doesn't help if you want a specific time or date.
>
> Even so, one could probably find a way to disable the counter.
> (I don't know if reset will reset the counter or not, otherwise
> one can always reload the device.)
>
> I was unsure from your original post if you meant the ability
> to generate bitfiles, or the ability to use them.
>
> If the device has internet access, you could use an NTP server
> to get the date/time.  That would take a lot of logic, though!
>
> -- glen

Where I have seen evaluation versions of IP with hardware time
limits, the clock cycles they count are internal to the core
and generated with a ring oscillator to prevent reset without
re-configuration. If your system can live with periodic
reconfiguration, then obviously this method can be bypassed
as well.

Regards,
Gabor
From: glen herrmannsfeldt on 9 Jun 2010 19:39
Gabor <gabor(a)alacron.com> wrote:
(snip)

> Where I have seen evaluation versions of IP with hardware time
> limits, the clock cycles they count are internal to the core
> and generated with a ring oscillator to prevent reset without
> re-configuration. If your system can live with periodic
> reconfiguration, then obviously this method can be bypassed
> as well.

Some devices naturally need a clock. I thought I remembered
this test on an ethernet MAC, which would be pretty hard to use
without a clock.

On the other hand, how hard is it to find the carry chains in
a design? If you can find the counter, it probably isn't so
hard to disable it without doing anything else to the design.

-- glen
From: Sudhir Singh on 10 Jun 2010 03:07
On Jun 10, 11:39 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu>
wrote:
> Gabor <ga...(a)alacron.com> wrote:
>
> (snip)
>
> > Where I have seen evaluation versions of IP with hardware time
> > limits, the clock cycles they count are internal to the core
> > and generated with a ring oscillator to prevent reset without
> > re-configuration.  If your system can live with periodic
> > reconfiguration, then obviously this method can be bypassed
> > as well.
>
> Some devices naturally need a clock.  I thought I remembered
> this test on an ethernet MAC, which would be pretty hard to use
> without a clock.  
>
> On the other hand, how hard is it to find the carry chains in
> a design?  If you can find the counter, it probably isn't so
> hard to disable it without doing anything else to the design.
>
> -- glen


Hi Guys,

Thanks for your replies. I think counting clock cycles will be a
viable option for me.

Cheers
Sudhir
First  |  Prev  | 
Pages: 1 2
Prev: Burn to an internal prom Spartan-3an
Next: Design passes synthesis and routing but fails on FPGA